Search Results

4882 results were found.

Print Results
1GL. (1) first-generation language (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: machine language


2GL. (1) second-generation language (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: assembly language


3D. (1) three-dimensional (ISO/IEC/IEEE 23026:2015 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 5) Syn: 3-D


3GL. (1) third-generation language (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: high order language


4GL. (1) fourth-generation language (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


5GL. (1) fifth-generation language (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


language. (1) definitions of concepts and rules for the specification of an ODP system from the viewpoint (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.2.1.1) Note: Thus, engineering language: definitions of concepts and rules for the specification of an ODP system from the engineering viewpoint.


domain. (1) set of objects, each of which is related by a characterizing relationship <X> to a controlling object (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 10.3)


federation. (1) a community of domains (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 5.1.2)


group. (1) set of objects with a particular characterizing relationship <X> (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 10.1)


interceptor. (1) engineering object in a channel, placed at a boundary between domains (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.11) Note: An interceptor performs checks to enforce or monitor policies on permitted interactions between basic engineering objects in different domains; performs transformations to mask differences in interpretation of data by basic engineering objects in different domains. An inter-subnetwork relay is an example of an interceptor


pattern. (1) abstract specification of a composition of objects that results in any instance of the composition having a given property, named by <X> (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.8)


A-0 context diagram. (1) the only context diagram that is a required for a valid IDEF0 model, the A-0 diagram contains one box, which represents the top-level function being modeled, the inputs, controls, outputs, and mechanisms attached to this box, the full model name, the model name abbreviation, the model's purpose statement, and the model's viewpoint statement (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0)


A-profile. (1) Application profile (ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)


A/B testing. (1) technique to determine the effectiveness of minor changes in a product or design where "A" represents the original version and "B" represents the modified version (ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.1)


ABC. (1) activity-based costing (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


abend. (1) abnormal end (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


abnormal end (abend). (1) termination of a process prior to completion (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: abort, exception


abort. (1) to terminate a process prior to completion (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: abend, exception


absent variant. (1) variant that is not determined or developed at the specific time (ISO/IEC 26554:2018 Information technology--Software and systems engineering-Tools and methods for product line testing, 3.1)


absolute address. (1) address that is permanently assigned to a device or storage location and that identifies the device or location without the need for translation or calculation (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: explicit address, specific address See Also: relative address, relocatable address, symbolic address, absolute assembler, absolute code, absolute instruction


absolute assembler. (1) assembler that produces absolute code (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: relocating assembler


absolute code. (1) code in which all addresses are absolute addresses (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: specific code See Also: relocatable code


absolute instruction. (1) computer instruction in which all addresses are absolute addresses (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: direct instruction, effective instruction, immediate instruction, indirect instruction


absolute loader. (1) loader that reads absolute machine code into main memory, beginning at the initial address assigned to the code by the assembler or compiler, and performs no address adjustments on the code (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: relocating loader


abstract class. (1) class that cannot be instantiated independently (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.1) Note: That is, instantiation must be accomplished via a subclass. A class for which every instance must also be an instance of a subclass in the cluster (a total cluster) is called an abstract class with respect to that cluster.


abstract data type. (1) data type for which only the properties of the data and the operations to be performed on the data are specified, without concern for how the data will be represented or how the operations will be implemented (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


abstract design. (1) generic form that needs specialization (further design work) to produce concrete designs (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) design aimed at producing designs (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


abstraction. (1) view of an object that focuses on the information relevant to a particular purpose and ignores the remainder of the information (ISO/IEC 19506:2012 Information technology -- Object Management Group Architecture-Driven Modernization (ADM) -- Knowledge Discovery Meta-Model (KDM), 4) (2) process of formulating a view (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) process of suppressing irrelevant detail to establish a simplified model, or the result of that process (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 6.3) See Also: data abstraction


AC. (1) actual cost (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


acceptability. (1) exposure to loss (financial or otherwise) that an organization is willing to tolerate from a risk (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: Risk acceptability can apply to an individual risk or to a collection of risks, such as the totality of risks confronting a project or enterprise. Acceptability can differ for different categories of risk and can depend on the cost of treatment or other factors.


acceptability criteria. (1) documented set of characteristics of a program's work products that if satisfied, forms a sufficient basis for judging each product's content to be acceptable to support a successful review or audit (IEEE 15288.2:2014 IEEE Standard for Technical Reviews and Audits on Defense Programs, 3.1)


acceptable. (1) meeting stakeholder expectations that can be shown to be reasonable or merited (ISO/IEC/IEEE 24765c:2014)


acceptance. (1) action by an authorized representative of the acquirer by which the acquirer assumes ownership of products as partial or complete performance of an agreement (ISO/IEC/IEEE 24748-5 Systems and software engineering--Life cycle management--Part 5: Software development planning, 3.1)


acceptance criteria. (1) criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) a set of conditions that is required to be met before deliverables are accepted (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) See Also: requirement, test criteria


acceptance test. (1) 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 (ISO/IEC 2382:2015 Information technology -- Vocabulary) See Also: acceptance testing, validation test


acceptance testing. (1) testing conducted to determine whether a system satisfies its acceptance criteria and to enable the customer to determine whether to accept the system (ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary) (2) formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a system or component (IEEE 1012-2016 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1) See Also: acceptance test, validation test


accepted deliverables. (1) products, results, or capabilities produced by a project and validated by the project customer or sponsors as meeting their specified acceptance criteria (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


access. (1) to obtain the use of a resource (ISO/IEC 2382:2015 Information technology -- Vocabulary)


access facility. (1) set of service primitives that allow a stub objects to negotiate the abstract and transfer syntax to be used for the operation data to be transmitted over the channel (ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 3.3.1)


access method. (1) technique to obtain the use of data, the use of storage in order to read or write data, or the use of an input-output channel to transfer data (ISO/IEC 2382:2015 Information technology -- Vocabulary)


access routine. (1) routine that provides access to a data structure that is hidden, usually because it is a global variable or used in an abstract data type. (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


access transparency. (1) distribution transparency which masks differences in data representation and invocation mechanisms to enable interworking between objects (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.4.1.1)


accessibility testing. (1) type of usability testing used to measure the degree to which a test item can be operated by users with the widest possible range of characteristics and capabilities (ISO/IEC/IEEE 29119-1:2013 Software and systems engineering--Software testing--Part 1: Concepts and definitions, 4.1)


accident. (1) unplanned event or series of events that results in death, injury, illness, environmental damage, or damage to or loss of equipment or property (IEEE 1228-1994 (R2002) IEEE Standard for Software Safety Plans, 3.1.1)


accountability. (1) degree to which the actions of an entity can be traced uniquely to the entity (ISO/IEC 25010:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--System and software quality models, 4.2.6.4)


accuracy. (1) qualitative assessment of correctness, or freedom from error (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) quantitative measure of the magnitude of error (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) Within the quality management system, accuracy is an assessment of correctness (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) See Also: precision


accuracy of measurement. (1) closeness of the agreement between the result of a measurement and the true value of the measurand (ISO/IEC TR 14143-3:2003 Information technology -- Software measurement -- Functional size measurement -- Part 3: Verification of functional size measurement methods, 3.1) Note: Accuracy is a qualitative concept. The term precision is not a synonym for "accuracy". [ISO/IEC Guide 99:2007 International vocabulary of metrology -- Basic and general concepts and associated terms] A true value is a value consistent with the definition of a given particular quantity and this is a value that would be obtained by a perfect measurement. In contexts where perfect measurement is not practically feasible, a conventional true value is a value attributed to a particular quantity and accepted, sometimes by convention, as having an uncertainty appropriate for a given purpose. 'Conventional true value', in the same reference, is sometimes called assigned value, best estimate of the value, conventional value or reference value. The accuracy can be expressed in terms of the Mean magnitude of relative error.


ACIA. (1) asynchronous communication interface adapter (ISO/IEC/IEEE 24765d:2015)


ACID. (1) Atomicity Consistency Isolation Durability (ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)


acknowledged system of systems. (1) system of systems (SoS) with recognized objectives, a designated manager, and resources for the SoS (ISO/IEC/IEEE 21841:2019 Systems and software engineering--Taxonomy of systems of systems, 3.2.1) Note: Constituent systems retain their independent ownership, objectives, funding, and development and sustainment approaches. Changes in the systems are based on cooperative agreements between the SoS and the system. Syn: acknowledged SoS


ACQ. (1) acquirer (ISO/IEC TR 29110-5-6-2:2014 Systems and software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 5-6-2: Systems engineering--Management and engineering guide: Generic profile group: Basic profile, 4.2)


acquire resources. (1) the process of obtaining team members, facilities, equipment, materials, supplies, and other resources necessary to complete project work (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


acquirer. (1) stakeholder that acquires or procures a product or service from a supplier (ISO/IEC/IEEE 12207:2017 Systems and software engineering--Software life cycle processes, 4.1) (ISO/IEC/IEEE 15288:2015 Systems and software engineering--System life cycle processes, 4.1.1) (ISO/IEC/IEEE 24748-1:2018 Systems and software engineering--Life cycle management--Part 1: Guidelines for life cycle management, 2.1) (2) person or organization that acquires or procures a system, software product, or software service (which can be part of a system) from a supplier (ISO/IEC TR 12182:2015 Systems and software engineering--Framework for categorization of IT systems and software, and guide for applying it, 3.13) (3) individual or organization that acquires or procures a system, software product or software service from a supplier (ISO/IEC 25040:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Evaluation process, 4.1) Note: The acquirer can be internal or external to the supplier organization. Acquisition of a software product can involve, but does not necessarily require, a legal contract or a financial transaction between the acquirer and supplier. Syn: buyer, owner, purchaser See Also: customer


acquisition. (1) process of obtaining a system, product, or service (ISO/IEC/IEEE 12207:2017 Systems and software engineering--Software life cycle processes, 3.1.2) (ISO/IEC/IEEE 15288:2015 Systems and software engineering--System life cycle processes, 4.1.2) (ISO/IEC/IEEE 24748-1:2018 Systems and software engineering--Life cycle management--Part 1: Guidelines for life cycle management, 3.2) (2) obtaining human and material resources necessary to perform project activities. Acquisition implies a cost of resources, and is not necessarily financial (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


acquisition strategy. (1) specific approach to acquiring products and services that is based on considerations of supply sources, acquisition methods, requirements specification types, contract or agreement types, and related acquisition risks (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


action. (1) element of a step that a user performs during a procedure (ISO/IEC 26514:2008 Systems and software engineering--requirements for designers and developers of user documentation, 4.2) (2) description of an operation to be taken in the formulation of a solution (ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.7) (3) something which happens (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.3) (4) user behavior that a system accepts as a request for a particular operation (ISO/IEC TR 25060:2010 Systems and software engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE)--Common Industry Format (CIF) for usability: General framework for usability-related information, 2.2)


action entry. (1) indication of the relevance of an action to a particular rule (ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.9)


action of interest. (1) action in a transaction which leads to a state change of significance to the transaction (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 13.7.1.2)


action signature. (1) specification of an action that comprises the name for the action, the number, names and types of its parameters, and an indication of the causality of the object that instantiates the action template (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.14)


action stub. (1) list of all the actions to be taken in the solution of a problem (ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.11)


activation. (1) one occurrence of a function's transformation of some subset of its inputs into some subset of its outputs (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.3)


activation constraint. (1) function's requirement for the presence of a non-empty object set in a particular arrow role as a precondition for some activation of the function (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.4)


active area. (1) (on-screen documentation) area that responds to user input (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary, 4.3) Example: a window, icon or text field


active enterprise object. (1) enterprise object that is able to fill an action role (ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.3.1)


active interconnection. (1) physical interaction mechanism allowing the action of one thing to cause a change or to stimulate an action in another thing (ISO/IEC/IEEE 24765i:2020)


active redundancy. (1) in fault tolerance, the use of redundant elements operating simultaneously to prevent, or permit recovery from, failures (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: standby redundancy


active text. (1) text displayed on the screen that responds to user input (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


active white space. (1) area around textual or graphical elements, not including margins, which breaks up text, separates topic and subtopic groupings, indicates hierarchical and topical relationships, highlights information, or makes text easier to read (ISO/IEC/IEEE 24765a:2011)


activity. (1) set of cohesive tasks of a process (ISO/IEC/IEEE 12207:2017 Systems and software engineering--Software life cycle processes) (ISO/IEC/IEEE 15288:2015 Systems and software engineering--System life cycle processes, 4.1.3) (ISO/IEC/IEEE 24748-1:2018 Systems and software engineering--Life cycle management--Part 1: Guidelines for life cycle management, 2.3) (2) a distinct, scheduled portion of work performed during the course of a project (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) (3) order submitted to the system under test (SUT) by a user or an emulated user demanding the execution of a data processing operation according to a defined algorithm to produce specific output data from specific input data and (if requested) stored data (ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.1) (4) defined body of work to be performed, including its required input information and output information (ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary) (5) set of cohesive tasks of a process, which transforms inputs into outputs (IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2) (6) element of work performed during the implementation of a process (ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary) (7) set of actions that consume time and resources and whose performance is necessary to achieve, or contribute to, the realization of one or more outcomes (ISO/IEC TR 24766:2009 Information technology--Systems and software engineering--Guide for requirements engineering tool capabilities, 3.1) (8) single-headed directed acyclic graph of actions, where occurrence of each action in the graph is made possible by the occurrence of all immediately preceding actions (i.e., by all adjacent actions which are closer to the head) (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.6) Note: An activity normally has an expected duration, cost, and resource requirements. Activities are often subdivided into tasks.


process flow
process flow



activity attributes. (1) multiple attributes associated with each schedule activity that can be included within the activity list. Activity attributes include activity codes, predecessor activities, successor activities, logical relationships, leads and lags, resource requirements, imposed dates, constraints, and assumptions. (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


activity duration. (1) the time in calendar units between the start and finish of a schedule activity (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) See Also: duration


activity group. (1) set of related activities (ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)


activity list. (1) a documented tabulation of schedule activities that shows the activity description, activity identifier, and a sufficiently detailed scope of work description so project team members understand what work is to be performed. (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


activity type. (1) classification of activities defined by the execution of the same algorithm (ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.2)


activity-based costing (ABC). (1) cost accounting method that allocates overhead costs based on specific production activities rather than allocating from a single overhead pool (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


activity-oriented WBS. (1) a work breakdown structure in which activities and tasks are denoted by verbs that indicate work to be accomplished. Each task name includes the work product or work products to be produced by that task. (Software Extension to the PMBOK(R) Guide Fifth Edition)


actor. (1) role (with respect to that action) in which the enterprise object fulfilling the role participates in the action (ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.3.2) (2) organization or CASE tool that supplies or acquires SEE services (ISO/IEC 15940:2013 Systems and software engineering--Software Engineering Environment Services, 2.10) (3) in UML, someone or something outside the system that interacts with the system (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: It can be of interest to specify which actor initiates that action.


actual cost (AC). (1) the realized cost incurred for the work performed on an activity during a specific time period (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) Syn: actual cost of work performed (ACWP) See Also: earned value management, earned value technique


actual depreciation. (1) true loss in value of an asset, determined only when the asset is sold (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


actual dollar analysis. (1) addressing inflation or deflation by using cash-flow amounts that represent actual amounts of money at the time of the cash flow (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: constant dollar analysis


actual duration. (1) the time in calendar units between the actual start date of the schedule activity and either the data date of the project schedule if the schedule activity is in progress or the actual finish date if the schedule activity is complete. (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


actual results. (1) set of behaviors or conditions of a test item, or set of conditions of associated data or the test environment, observed as a result of test execution (ISO/IEC/IEEE 29119-1:2013 Software and systems engineering--Software testing--Part 1: Concepts and definitions, 4.2) Example: outputs to hardware, changes to data, reports, and communication messages sent


ACWP. (1) actual cost of work performed (ISO/IEC/IEEE 24765c:2014)


ad hoc reviewing. (1) unstructured independent review technique (ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.1)


adaptability. (1) degree to which a product or system can effectively and efficiently be adapted for different or evolving hardware, software or other operational or usage environments (ISO/IEC 25010:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--System and software quality models, 4.2.8.1) Note: Adaptability includes the scalability of internal capacity, such as screen fields, tables, transaction volumes, and report formats. Adaptations include those carried out by specialized support staff, business or operational staff, or end users. If the system is to be adapted by the end user, adaptability corresponds to suitability for individualization as defined in ISO 9241-110. See Also: flexibility


adaptation data. (1) data used to adapt a program to a given installation site or to given conditions in its operational environment (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


adaptation parameter. (1) variable that is given a specific value to adapt a program to a given installation site or to given conditions in its operational environment (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: the variable Installation_Site_Latitude


adapter. (1) object adapter (ISO/IEC 19500-2:2012 Information technology --Object Management Group--Common Object Request Broker Architecture (CORBA)--Part 2: Interoperability, 3.2.1)


adaptive maintenance. (1) modification of a software product, performed after delivery, to keep a software product usable in a changed or changing environment (IEEE 14764-2006 Software Engineering - Software Life Cycle Processes - Maintenance, 3.1) Example: The operating system is upgraded and some changes are made to accommodate the new operating system. Note: Adaptive maintenance provides enhancements necessary to accommodate changes in the environment in which a software product must operate. These changes are those that must be made to keep pace with the changing environment.


added source statements. (1) count of source statements that were created specifically for the software product (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


additive weighting. (1) assignment of different values to increase the importance of selected decision attributes (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: compensatory decision technique, nondimensional scaling, analytic hierarchy process


address. (1) number, character, or group of characters that identifies a given device or storage location (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) to refer to a device or storage location by an identifying number, character, or group of characters (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) to deal with, to take into consideration; (specifically) to decide whether and when a defined documentation topic is to be included, either directly or by reference to another document; to decide whether an item is to be recorded prior to the test execution (in a tool or not in a tool), recorded during the test execution, recorded post-test execution, not recorded (addressed by the process), or excluded (ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)


address field. (1) field of a computer instruction that contains addresses, information necessary to derive addresses, or values of operands (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: address part See Also: operation field


address format. (1) number and arrangement of address fields in a computer instruction. (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) number and arrangement of elements within an address, such as the elements needed to identify a particular channel, device, disk sector, and record in magnetic disk storage (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: n-address instruction, n-plus-one address instruction


address modification. (1) arithmetic, logical, or syntactic operation performed on an address (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: effective address, indexed address, relative address, relocatable address


address space. (1) addresses that a computer program can access (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) number of memory locations that a central processing unit can address (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: null Note: In some systems, this is the set of physical storage locations that a program can access, disjoint from other programs, together with the set of virtual addresses referring to those storage locations, which are accessible by other programs.


addressing exception. (1) exception that occurs when a program calculates an address outside the bounds of the storage available to it (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: data exception, operation exception, overflow exception, protection exception, underflow exception


addressing mode. (1) method to search operand position in the instruction set architecture for a central processing unit (ISO/IEC/IEEE 24765d:2015)


addressing range. (1) address space specified and used by the instruction system of a computer (ISO/IEC/IEEE 24765d:2015) Note: An addressing range depends on the bits of address lines and addressing mode.


adjusted size. (1) a size based on the functional size multiplied by the technical complexity adjustment (ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10) Note: This measure does not represent functional size.


ADM. (1) architecture-driven modernization (ISO/IEC 19506:2012 Information technology -- Object Management Group Architecture-Driven Modernization (ADM) -- Knowledge Discovery Meta-Model (KDM), 4)


adoption process. (1) set of activities by which an organization brings CASE tools into widespread use (ISO/IEC TR 14471:2007 Information technology--Software engineering--Guidelines for the adoption of CASE tools, 2.1.2)


ADT. (1) Abstract Data Type (ISO/IEC 19500-2:2012 Information technology --Object Management Group--Common Object Request Broker Architecture (CORBA)--Part 2: Interoperability, 3.3)


advanced profile. (1) profile targeted at very small enterprises (VSEs) which want to sustain and grow as an independent competitive system or software development business (ISO/IEC 29110-2-1:2015 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 2-1: Framework and taxonomy, 4.3)


AE(I). (1) Application Entity (Invocation) (ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview) (2) architecture evaluation (ISO/IEC/IEEE 42030:2019 Software, systems, and enterprise--Architecture evaluation framework, 3.4)


afferent. (1) pertaining to a flow of data or control from a subordinate module to a superordinate module in a software system (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: efferent


agent. (1) active enterprise object that has been delegated something (authorization, responsibility, provision of a service, etc.) by, and acts for, a party (in exercising the authorization, carrying out the responsibility, providing the service, etc.) (ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.6.8) Note: An agent can be a party or can be the ODP system or one of its components. Another system in the environment of the ODP system can also be an agent. The delegation can have been direct, by a party, or indirect, by an agent of the party having authorization from the party to so delegate.


aggregate. (1) composition of several implemented system elements that are assembled, on which a set of verification actions or validation actions is applied (ISO/IEC TS 24748-6:2016 Systems and software engineering--Life cycle management--Part 6: System integration engineering, 3.1.2)


aggregate responsibility. (1) broadly stated responsibility that is eventually refined as specific properties and constraints (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.3)


aggregation. (1) derived relationship between two elements that are groups of other elements that represents all individual relationships between the grouped elements of the two groups (ISO/IEC 19506:2012 Information technology -- Object Management Group Architecture-Driven Modernization (ADM) -- Knowledge Discovery Meta-Model (KDM), 4)


aggregation method. (1) method that combines a set of measurement values to create a composite value (ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.1) Note: Aggregation methods are based on compensatory or non-compensatory models.


agile environment. (1) organizational culture, infrastructure, and methodologies that support agile development (ISO/IEC/IEEE 26515: 2018 Systems and software engineering: Developing information for users in an agile environment, 4.2)


agile team. (1) organization or team using agile development methods and approaches (ISO/IEC/IEEE 26515: 2018 Systems and software engineering: Developing information for users in an agile environment, 3.3)


agreement. (1) mutual acknowledgment of terms and conditions under which a working relationship is conducted (ISO/IEC/IEEE 12207:2017 Systems and software engineering--Software life cycle processes, 3.1.5) (ISO/IEC/IEEE 15288:2015 Systems and software engineering--System life cycle processes, 4.1.4) (ISO/IEC/IEEE 24748-1:2018 Systems and software engineering--Life cycle management--Part 1: Guidelines for life cycle management, 2.5) (2) any document or communication that defines the initial intentions of a project. This can take the form of a contract, memorandum of understanding (MOU), letters of agreement, verbal agreements, email, etc. (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) See Also: contract


AHP. (1) analytic hierarchy process (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


algebraic language. (1) programming language that permits the construction of statements resembling algebraic expressions, such as Y = X + 5 (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: FORTRAN See Also: algorithmic language, list processing language, logic programming language


algorithm. (1) finite set of well-defined rules for the solution of a problem in a finite number of steps (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) sequence of operations for performing a specific task (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) finite ordered set of well-defined rules for the solution of a problem (ISO/IEC 2382:2015 Information technology -- Vocabulary) Example: a complete specification of a sequence of arithmetic operations for evaluating sine x to a given precision


algorithmic language. (1) programming language designed for expressing algorithms (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: ALGOL See Also: algebraic language, list processing language, logic programming language


alias. (1) alternate name for an IDEF1X model construct (class, responsibility, entity, or domain) (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.4)


allocated baseline. (1) approved requirements for a product, subsystem or component, describing the functional, performance, interoperability, and interface requirements that are allocated from higher-level requirements and the verifications required to demonstrate achievement of those requirements, as established at a specific point in time and documented in the allocated configuration documentation (IEEE 15288.1:2014 IEEE Standard for Application of Systems Engineering on Defense Programs, 3.1) See Also: developmental configuration, functional baseline, product baseline, allocated configuration identification


allocated configuration identification. (1) in configuration management, the current approved specifications governing the development of configuration items that are part of a higher-level configuration item (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: Each specification defines the functional characteristics that are allocated from those of the higher-level configuration item, establishes the tests required to demonstrate achievement of its allocated functional characteristics, delineates necessary interface requirements with other associated configuration items, and establishes design constraints, if any. See Also: functional configuration identification, product configuration identification. allocated baseline


allocated requirement. (1) requirement that levies all or part of the performance and functionality of a higher-level requirement on a lower level architectural element or design component (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


allocation. (1) process of distributing requirements, resources, or other entities among the components of a system or program (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) result of the distribution of requirements, resources, or other entities among the components of a system or program (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: Allocation can be made entirely to hardware, software, or humans, or to some combination to be resolved upon further functional decomposition.


allocation of an entitlement. (1) process of assigning some or all of a given entitlement to a subsidiary or other associated organizational unit which manages its own entitlement schema library (ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.1) Note: The entitlement schema enables the recording of entitlement allocations.


alpha testing. (1) first stage of testing before a product is considered ready for commercial or operational use (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: often performed only by users within the organization developing the software See Also: beta testing


alphanumeric. (1) pertaining to data that consists of letters, digits, and usually other characters, such as punctuation marks, as well as to processes and functional units that use the data (ISO/IEC 2382:2015 Information technology -- Vocabulary)


ALS. (1) Application Layer Structure (ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)


alternate flow. (1) part of a use case that describes its alternative implementations (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: It is also used to describe error conditions, since errors can be considered a kind of alternative. Syn: alternate path


alternate key. (1) candidate key of an entity other than the primary key (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.5) Note: [key style]


alternatives generation. (1) a technique used to develop as many potential options as possible in order to identify different approaches to execute and perform the work of the project (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


AM. (1) acquisition manager (ISO/IEC TR 29110-5-6-3:2019 Systems and software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 5-6-3: Systems engineering: Management and engineering guide: Generic profile group: Intermediate profile, 4.3)


analog. (1) pertaining to continuously variable physical quantities or to data presented in a continuous form, as well as to processes and functional units that use the data (ISO/IEC 2382:2015 Information technology -- Vocabulary)


analog computer. (1) computer whose operations are analogous to the behavior of another system and that accepts, processes, and produces analog data (ISO/IEC 2382:2015 Information technology -- Vocabulary) Example: an abacus


analogous estimating. (1) a technique for estimating the duration or cost of an activity or a project using historical data from a similar activity or project (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


analysis. (1) process of studying a system by partitioning the system into parts (functions, components, or objects) and determining how the parts relate to each other (ISO/IEC/IEEE 24765e:2015) (2) investigation and collection phase of development that aims to specify types of users and their information needs (ISO/IEC/IEEE 26512:2017 Systems and software engineering--Requirements for acquirers and suppliers of information for users, 4.2) Example: test


analyst. (1) member of the technical community who is skilled and trained to define problems and to analyze, develop, and express algorithms (ISO/IEC/IEEE 24765e:2015) Example: systems engineer, business analyst


analytic hierarchy process (AHP). (1) use of matrixes to manage pair-wise relationships in decision-making (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: additive weighting, nondimensional scaling, compensatory decision technique


analytical techniques. (1) various techniques used to evaluate, analyze, or forecast potential outcomes based on possible variations of project or environmental variables and their relationships with other variables (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


analyzability. (1) degree of effectiveness and efficiency with which it is possible to assess the impact on a product or system of an intended change to one or more of its parts, or to diagnose a product for deficiencies or causes of failures, or to identify parts to be modified (ISO/IEC 25010:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--System and software quality models, 4.2.7.3) (2) degree of effectiveness and efficiency with which an IT service can be analyzed for deficiencies, gaps, and failures (ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.8.1) Note: Implementation can include providing mechanisms for the product or system to analyze its own faults and provide reports before or after a failure or other event. Syn: analysability See Also: modifiability


ancestor (of a class). (1) generic ancestor of the class or a parent of the class or an ancestor of a parent of the class (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.6) See Also: generic ancestor, reflexive ancestor


ancestral box. (1) box related to a specific diagram by a hierarchically consecutive sequence of one or more parent/child relationships (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.6)


ancestral diagram. (1) diagram that contains an ancestral box (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.7)


anchor point. (1) a milestone in software scheduling at which a major project life cycle transition occurs (Software Extension to the PMBOK(R) Guide Fifth Edition)


annotate. (1) command used for listing the latest version of each program's source code line, along with the date, the file version it was introduced, and the person who committed it (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


annotated topic list (ATL). (1) list of all topics to be included in an information-development project with annotations that can include writer, where used, file name, and additional data (ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.2)


annotation. (1) further documentation accompanying a requirement (ISO/IEC/IEEE 24765e:2015) (2) label represented as text near to the object it is associated with (ISO/IEC 15909-2:2011 Software and system engineering -- High-level Petri nets -- Part 2: Transfer format, 4.1.1) Example: background information or descriptive material


announcement. (1) interaction (invocation) initiated by a client object, resulting in the conveyance of information from that client object to a server object, requesting a function to be performed by that server object (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.3) Example: the initiation of the sending of a message in a messaging system


annual equivalent. (1) representation of a cash flow as a series of equal annual payments (at a stated interest rate) over the planning horizon (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: AE(i) See Also: future worth, present worth


annual percentage rate (APR). (1) nominal annual interest rate (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


annuity. (1) amount of a series of equal payments at regular intervals over a planning horizon (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


anomaly. (1) anything observed in the documentation or operation of a system that deviates from expectations based on previously verified system, software, or hardware products or reference documents (IEEE 1012-2016 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)


ANSI. (1) American National Standards Institute (ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)


anticipatory buffering. (1) buffering technique in which data are stored in a buffer in anticipation of a need for the data (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: dynamic buffering, simple buffering


anticipatory paging. (1) storage allocation technique in which pages are transferred from auxiliary storage to main storage in anticipation of a need for those pages (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: demand paging


AOA. (1) analysis of alternatives (IEEE 15288.2:2014 IEEE Standard for Technical Reviews and Audits on Defense Programs, 3.2) Syn: AoA


AON. (1) Activity-on-Node (ISO/IEC/IEEE 24765c:2014) See Also: precedence diagramming method


AP(I). (1) Application Process (Invocation) (ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)


aperiodic task. (1) task activated on demand (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: asynchronous task


API. (1) Application Program Interface (ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview) (2) application programming interface (ISO/IEC 19770-2:2015 (corr 2017), Information technology -- Software asset management -- Part 2: Software identification tag, 3.2)


applicability to a functional domain. (1) the ability of an FSM method to take into account the characteristics of functional user requirements (FUR) which are pertinent to FSM in a functional domain (ISO/IEC TR 14143-3:2003 Information technology -- Software measurement -- Functional size measurement -- Part 3: Verification of functional size measurement methods, 3.2)


applicant. (1) person who has submitted an application to be admitted into the certification process (ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.1)


application. (1) system for collecting, saving, processing, and presenting data by means of a computer (ISO/IEC 24570:2005 Software engineering -- NESMA functional size measurement method version 2.1 -- Definitions and counting guidelines for the application of Function Point Analysis) (ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.1) (2) a coherent collection of automated procedures and data supporting a business objective (ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10) (3) cohesive collection of automated procedures and data supporting a business objective, consisting of one or more components, modules, or subsystems (ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.2) Example: accounts payable, accounts receivable, payroll, procurement, shop production, assembly line control, air search radar, target tracking, weapons firing, flight line scheduling and passenger reservations Note: The term application is generally used when referring to a component of software that can be executed. It consists of one or more components, modules, or subsystems. Syn: application system See Also: application software, information system


application administration function. (1) functions performed by users which include installation, configuration, application backup, maintenance (patching and upgrading) and de-installation (ISO/IEC 25051:2014 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing, 4.1.3)


application architecture. (1) architecture including the architectural structure and rules (e.g. common rules and constraints) that constrains a specific member product within a product line (ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.1) (2) architecture concept, including the architectural structure and rules (e.g. common rules and constraints), and architecture artifacts (such as descriptions) that constrains a specific member product within a product line (ISO/IEC 26552:2019 Software and systems engineering--Tools and methods for product line architecture design, 3.1) Note: The application architecture captures the high-level design of a specific member product of a product line.


application area. (1) group of applications that have common components or characteristics, such as similar technologies or production methods, similar customers (i.e., internal versus external, government versus commercial) or a common industry sector (i.e., utilities, automotive, aerospace, information technologies) (ISO/IEC/IEEE 24765g:2018)


application asset. (1) output of a specific application engineering process (e.g. application realization) that can be exploited in other lifecycle processes of application engineering and can be adapted as a domain asset based on a product management decision (ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.2) Note: Application asset encompasses requirements, an architectural design, components, and tests.


application assets in requirements. (1) application-specific artifacts produced during application requirements engineering, such as application requirements specifications and application requirements models (ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.1)


application boundary. (1) the border between the application and its environment of other applications and users (ISO/IEC 24570:2005 Software engineering -- NESMA functional size measurement method version 2.1 -- Definitions and counting guidelines for the application of Function Point Analysis)


application component. (1) component that is selected, reused or newly developed for a member product (ISO/IEC 26553:2018 Information technology-Software and systems engineering- Tools and methods for product line realization, 3.1)


application configuration. (1) derivation for member product specific executables from domain assets in realization (ISO/IEC 26557:2016 Software and systems engineering -- Methods and tools for variability mechanisms in software and systems product line, 3.1) (2) composition results of an application by both binding variability and adding application specific variability (ISO/IEC 26558:2017 Software and systems engineering -- Methods and tools for variability modelling in software and systems product line, 3.1) (3) structure of a member product, including application components and application interfaces (ISO/IEC 26555:2015 Software and systems engineering--Tools and methods for product line technical management, 3.2)


application design. (1) process of application engineering where a single application architecture conforming to the domain architecture is derived (ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.3)


application engineering. (1) the process of constructing or refining application systems by reusing assets (IEEE 1517-2010 IEEE Standard for Information Technology--System and software life cycle processes--Reuse processes, 3) (2) life cycle consisting of a set of processes in which the application assets and member products of the product line are implemented and managed by reusing domain assets in conformance to the domain architecture and by binding the variability of the platform (ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.4)


application engineering process. (1) processes for developing a member product in a product line (ISO/IEC 26555:2015 Software and systems engineering--Tools and methods for product line technical management, 3.1)


application frameworks. (1) subsystem design made up of a collection of abstract and concrete classes and interfaces between them (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: Frameworks are often instantiation of a number of patterns.


application function point count. (1) a count that provides a measure of the functionality the application provides to the end-user (ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10) (2) the size of an application expressed in function points (ISO/IEC 24570:2005 Software engineering -- NESMA functional size measurement method version 2.1 -- Definitions and counting guidelines for the application of Function Point Analysis) (3) activity of applying ISO/IEC 20926:2009 to measure the functional size of an application (ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.4) Note: i.e., the functionality already provided to the user or that is still to be provided. With it, the effort required to support the realized application can also be determined.


application functional size. (1) measure of the functionality that an application provides to the user, determined by the application function point count (ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.3)


application generator. (1) code generator that produces programs to solve one or more problems in a particular application area (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: a payroll generator


application interface. (1) interface that is selected, reused or newly developed by a member product (ISO/IEC 26553:2018 Information technology-Software and systems engineering- Tools and methods for product line realization, 3.3)


application management. (1) domain responsible for all of the tasks and activities that are aimed at managing, supporting, maintaining, and renewing existing applications and related data structures (ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.2) Note: Application management includes all of the tasks, responsibilities, and activities that serve to bring applications into a state where they meet the requirements and needs of their owners throughout the entire life cycle of the business processes that are supported by the applications.


application management organization. (1) organizational unit that is responsible for application management for one or more applications (ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.3) Note: An application management organization can be an internal or external unit in relation to the user organization.


application object. (1) component that is directly related to or forms part of an application (ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.4) Example: Programs, sources, databases, documentation, data structures, test files, and scripts.


application portfolio. (1) collection of applications managed by an application management organization or an entity within that application management organization (ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.5) Note: The scope of the application portfolio can be the entire portfolio of that application management organization, but it can also be the applications of one or some customer organizations of entity within part of a certain customer organization.


application problem. (1) problem submitted by an end user and requiring information processing for its solution (ISO/IEC 2382:2015 Information technology -- Vocabulary)


application programming interface (API). (1) software component that allows software applications to communicate with one another (ISO/IEC/IEEE 26531:2015 Systems and software engineering -- Content management for product lifecycle, user and service management documentation, 4,1)


application realization. (1) process of application engineering that develops application assets, some of which can be derived from domain assets, and member products based on the application architecture and the sets of application assets and domain assets (ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.5) (2) one of the application engineering processes that includes detailed design and implementation (ISO/IEC 26553:2018 Information technology-Software and systems engineering- Tools and methods for product line realization, 3.4)


application requirements analysis. (1) subprocess that understands all application specific requirements, scrutinizes incorrect and inconsistent application requirements through modelling, and then analyses and negotiates application requirements that cannot be satisfied through the domain requirements (ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.3)


application requirements elicitation. (1) subprocess for identifying stakeholders relevant to an application, eliciting application specific requirements, and binding the appropriate variants (ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.2)


application requirements management. (1) subprocess that manages traceability and changes on application requirements (ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.6)


application requirements specification. (1) subprocess that documents the application specific requirements and integrates it with the domain requirements specification whose variants are bound (ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.4)


application requirements verification and validation. (1) subprocess that confirms that the application specific requirements are consistent and feasible and ensures that the bound variants satisfy the specific product's requirements (ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.5)


application software. (1) software designed to help users perform particular tasks or handle particular types of problems, as distinct from software that controls the computer itself (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary, 4.5) (2) software or a program that is specific to the solution of an application problem (ISO/IEC 2382:2015 Information technology -- Vocabulary) (3) software designed to fulfill specific needs of a user (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (4) software of an application (ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.6) Note: Application software is the software that the application management organization produces, services, and maintains. There is also system software: the software to produce and maintain the application software and to run the application software on its platform. The application management organization is one of the users of the system software. See Also: application


application specific integrated circuit (ASIC). (1) integrated circuit customized for a particular use (ISO/IEC/IEEE 24765d:2015) Syn: application-specific integrated circuit


application test asset. (1) application-specific test asset that has reuse potential (ISO/IEC 26554:2018 Information technology--Software and systems engineering-Tools and methods for product line testing, 3.3)


application testing. (1) sub-process of application engineering where domain test artefacts are reused to uncover evidence of defects in the application (ISO/IEC 26554:2018 Information technology--Software and systems engineering-Tools and methods for product line testing, 3.2)


application variability model. (1) variability model for a particular application including variability binding results, application specifically modified variability and application specifically added variability (ISO/IEC 26558:2017 Software and systems engineering -- Methods and tools for variability modelling in software and systems product line, 3.2)


application-oriented language. (1) computer language with facilities or notations applicable primarily to a single application area (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: a language for computer-assisted instruction or hardware design See Also: authoring language, specification language, query language


application-specific component. (1) component that is developed for a specific member product (ISO/IEC 26553:2018 Information technology-Software and systems engineering- Tools and methods for product line realization, 3.5)


application-specific requirements. (1) requirements specific to an application or requirements not covered in domain requirements (ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.9) Syn: application specific requirements


applying leads and lags. (1) a technique that is used to adjust the amount of time between predecessor and successor activities (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


apportioned effort. (1) an activity where effort is allotted proportionately across certain discrete efforts and not divisible into discrete efforts (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) Note: Apportioned effort is one of three earned value management (EVM) types of activities used to measure work performance. See Also: discrete effort


appraisal findings. (1) results of an appraisal that identify the most important issues, problems, or opportunities for process improvement within the appraisal scope (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: Appraisal findings are inferences drawn from corroborated objective evidence.


appraisal participants. (1) members of the organizational unit who participate in providing information during an appraisal (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


appraisal team leader. (1) person who leads the activities of an appraisal and has satisfied qualification criteria for experience, knowledge, and skills defined by the appraisal method (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


appropriateness recognizability. (1) degree to which users can recognize whether a product or system is appropriate for their needs (ISO/IEC 25010:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--System and software quality models, 4.2.4.1) (2) degree to which an IT service provides results that are appropriate for the user needs (ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.2.1) Note: Appropriateness recognizability will depend on the ability to recognize the appropriateness of the product or system's functions from initial impressions of the product or system or any associated documentation. The information provided by the product or system can include demonstrations, tutorials, documentation or, for a web site, the information on the home page. See Also: functional appropriateness


approval. (1) notification by an authorized representative that an information item appears to satisfy requirements and is complete (ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.1) Note: Such approval does not shift responsibility from the supplier to meet requirements under a two-party situation.


approval authority. (1) person (or persons) or organization (or organizations) responsible for approving activities, artifacts, and other aspects of the system during its life cycle (ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.5.2) (ISO/IEC/IEEE 24765h:2019) Note: The approval authority can include multiple entities, e.g. individuals or organizations. These can include different entitles with different levels of approval and/or different areas of interest. In two-party situations, approval authority often rests with the acquirer. In regulatory situations, the approval authority can be a third party such as a governmental organization or its agent. In other situations, e.g. the purchase of off-the-shelf products developed by a single-party, the independence of the approval authority can be a relevant issue to the acquirer.


approved modification. (1) disposition of one or more proposed changes authorizing change to any SCIs (ISO/IEC/IEEE 24765i:2020) Note: There can be a many-to-many relationship of "proposed change" to "approved modification". A proposed change can cause modifications in several SCIs (even if only to the code and its test case). A modification can originate from several proposed changes, approved simultaneously or over a period of time while the modification is still in progress.


arc. (1) directed edge of a net which can connect a place to a transition or a transition to a place, normally represented by an arrow (ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 2.1.1)


arc annotation. (1) expression that can involve constants, variables and operators used to annotate an arc of a net (ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 2.1.1.3) Note: The expression evaluates to a multiset over the type of the arc's associated place.


architect. (1) person, team, or organization responsible for systems architecture (ISO/IEC/IEEE 24765e:2015)


architecting. (1) process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system's life cycle (ISO/IEC/IEEE 42010:2011 Systems and software engineering--Architecture description, 3.1) Note: Architecting takes place in the context of an organization or a project. The entity to be architected can be of several kinds, as illustrated in the following examples: system, enterprise, solution, business, data, application, information technology, mission, product, service, software. Certifying the proper implementation of an architecture is sometimes captured as a formal statement by the architect to the client or user that the system, as built, meets the criteria as ready for use.


architectural design. (1) process of defining a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) result of defining a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: functional design


architectural design phase. (1) life-cycle phase in which a system's general architecture is developed, thereby fulfilling the requirements laid down by the software requirements document and detailing the implementation plan in response to it (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


architectural design review. (1) joint acquirer-supplier review to evaluate the technical adequacies of the software architectural design as depicted in the software design descriptions (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


architectural structure. (1) physical or logical layout of the components of a system design and their internal and external connections (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: function-oriented (structured) design, object-oriented design, and data structure-oriented design


architectural style. (1) definition of a family of systems in terms of a pattern of structural organization (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) characterization of a family of systems that are related by sharing structural and semantic properties (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: pipes and filters, layers, rule-based systems, and blackboards


architecture. (1) [system] fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution (ISO/IEC/IEEE 12207:2017 Systems and software engineering--Software life cycle processes, 3.1.6) (ISO/IEC/IEEE 42010:2011 Systems and software engineering--Architecture description, 3.2) (ISO/IEC/IEEE 15288:2015 Systems and software engineering--System life cycle processes, 4.1.5) (ISO/IEC/IEEE 24748-1:2018 Systems and software engineering--Life cycle management--Part 1: Guidelines for life cycle management, 2.6) (2) set of rules to define the structure of a system and the interrelationships between its parts (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 6.6) (3) fundamental concepts or properties of an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes (ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.3) Note: Architectures can address a wide range of concerns, expressed, for example, through architecture views and models, as illustrated in the following examples associated with particular kinds of architectures such as security architecture, functional architecture, physical architecture, resilience architecture. See Also: component, module, subprogram, routine


architecture collection. (1) group of architectures held by an organization that is subject to governance and management by the organization as a whole (ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.4) Note: The architectures in the collection can have relationships with each other (as in the case of product lines). The architectures in the collection can be based on the same reference architecture.


architecture description (AD). (1) work product used to express an architecture (ISO/IEC/IEEE 42010:2011 Systems and software engineering--Architecture description, 3.3) Syn: architectural description


architecture entity. (1) thing being considered, described, discussed, studied or otherwise addressed during the architecting effort (ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.6) (2) thing being characterized by an architecture (ISO/IEC/IEEE 42030:2019 Software, systems, and enterprise--Architecture evaluation framework, 3.3) Example: The following are kinds of architecture entities that can be dealt with by the architecture processes: enterprise, organization, solution, system (including software systems), subsystem, business, data (as a data element or data structure), application, information technology (as a collection), mission, product, service, software item, hardware item, product line, family of systems, system of systems, collection of systems, collection of applications. Note: When referring to the architecture itself of these architecture entities, it is common practice to place the name of the kind of entity in front of the word architecture. For example, the phrase system architecture is used when the thing being dealt with during the architecting effort is a system. The fundamental concepts or properties of the architecture entity are usually intended to be embodied in the entity's components, the relationships between components, and the relationships between the entity and its environment.


architecture evaluation (AE). (1) judgment about one or more architectures with respect to the specified evaluation objectives (ISO/IEC/IEEE 42030:2019 Software, systems, and enterprise--Architecture evaluation framework, 3.4) Example: Various kinds of judgments could be made during an architecture evaluation, such as validating that architectures address the concerns of stakeholders, assessing the quality of architectures with respect to their intended purpose, assessing the value of architectures or architecture entities to their stakeholders, determining whether architecture entities address their intended purpose, providing knowledge and information about architecture entities and identifying risks and opportunities associated with architectures.


architecture evaluation framework. (1) conventions, principles and practices for evaluating architectures (3.1) in a consistent and repeatable manner (ISO/IEC/IEEE 42030:2019 Software, systems, and enterprise--Architecture evaluation framework, 3.5) Example: Architecture Tradeoff Analysis Method (ATAM), the Method Framework and QUASAR method and Analysis of Alternatives (AoA). Note: This framework can be generic in nature or specific to a domain of application, a collection of concerns to be examined or a methodology. The evaluation framework can consist of different sub-architecture frameworks for an entity with many layers or levels. These could be defined and consolidated as part of the comprehensive architecture framework package. Syn: AE


architecture framework. (1) conventions, principles and practices for the description of architectures established within a specific domain of application or community of stakeholders (ISO/IEC/IEEE 12207:2017 Systems and software engineering--Software life cycle processes, 3.1.7) (ISO/IEC/IEEE 42010:2011 Systems and software engineering--Architecture description, 3.4) (ISO/IEC/IEEE 15288:2015 Systems and software engineering--System life cycle processes, 4.1.6) (ISO/IEC/IEEE 24748-1:2018 Systems and software engineering--Life cycle management--Part 1: Guidelines for life cycle management, 2.7) (2) conventions, principles and practices for use by architecture-related activities that have been established within a specific domain of application or community of stakeholders (ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.7) Example: Generalised Enterprise Reference Architecture and Methodologies (GERAM) [ISO 15704], Reference Model of Open Distributed Processing (RM-ODP) [ISO/IEC 10746]


architecture view. (1) work product expressing the architecture of a system from the perspective of specific system concerns (ISO/IEC/IEEE 12207:2017 Systems and software engineering--Software life cycle processes, 3.1.8) (ISO/IEC/IEEE 42010:2011 Systems and software engineering--Architecture description, 3.5) (ISO/IEC/IEEE 15288:2015 Systems and software engineering--System life cycle processes, 4.1.7) (ISO/IEC/IEEE 24748-1:2018 Systems and software engineering--Life cycle management--Part 1: Guidelines for life cycle management, 2.8) See Also: architecture viewpoint


architecture viewpoint. (1) work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns (ISO/IEC/IEEE 12207:2017 Systems and software engineering--Software life cycle processes, 3.1.9) (ISO/IEC/IEEE 42010:2011 Systems and software engineering--Architecture description, 3.6) (ISO/IEC/IEEE 15288:2015 Systems and software engineering--System life cycle processes, 4.1.8) (ISO/IEC/IEEE 24748-1:2018 Systems and software engineering--Life cycle management--Part 1: Guidelines for life cycle management, 2.9) See Also: architecture view


architecture-driven modernization (ADM). (1) process of understanding and evolving existing software assets of a system of interest (ISO/IEC 19506:2012 Information technology -- Object Management Group Architecture-Driven Modernization (ADM) -- Knowledge Discovery Meta-Model (KDM), 4) Note: ADM does not preclude source-to-source migrations (where appropriate), but encourages user organizations to consider modernization from an analysis and design perspective.


archival page. (1) content that is preserved as a record and not expected to change (ISO/IEC/IEEE 23026:2015 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 4.1) Note: Due to technology upgrades, some archival pages cannot be readily rendered unless they are upgraded along with active pages


archiving. (1) process of placing a version of a document in a less frequently used storage area (ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.3)


argument. (1) independent variable (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) specific value of an independent variable (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) constant, variable, or expression used in a call to a software module to specify data or program elements to be passed to that module (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: the variable m in the equation E = mc2


arity. (1) number of roles that participate in a relationship (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2) Note: A binary relationship has an arity of two. An n-ary relationship has an arity of n. (n>2) sometimes known as the "degree" of a relationship.


arranging. (1) activity of sequencing attributes in a transactional function (ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.5)


array. (1) an n-dimensional ordered set of data items identified by a single name and one or more indices, so that each element of the set is individually addressable (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: a matrix, table, or vector


arrow. (1) directed line, composed of one or more connected arrow segments in a single diagram from a single source (box or diagram boundary) to a single use (box or diagram boundary) (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.8) (2) graphic presentation of a logical relationship between schedule activities in the precedence diagramming method (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: arrow segment, boundary arrow, internal arrow


arrow label. (1) noun or noun phrase associated with an arrow segment to signify the arrow meaning of the arrow segment (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.9) Note: Specifically, an arrow label identifies the object type set that is represented by an arrow segment.


arrow meaning. (1) object types of an object type set, regardless of how these object types can be collected, aggregated, grouped, bundled, or otherwise joined within the object type set (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.10) (2) a review conducted to evaluate the manner in which the requirements for a system have been allocated to configuration items, the system engineering process that produced the allocation, the engineering planning for the next phase of the effort, manufacturing considerations, and the planning for production engineering Example: a physical thing, a data element


arrow role. (1) relationship between an object type set represented by an arrow segment and the activity represented by the box to which the arrow segment is attached (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.12) Note: There are four arrow roles: input, control, output, and mechanism.


arrow segment. (1) directed line that originates at a box side, arrow junction (branch or join), or diagram boundary and terminates at the next box side, arrow junction (branch or join), or diagram boundary that occurs in the path of the line (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.13)


artifact. (1) role (with respect to an action) in which the enterprise object fulfilling the role is referenced in the action (ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.3.3) Note: An enterprise object that is an artifact in one action can be an actor in another action. Syn: artefact


artificial intelligence (AI). (1) branch of computer science devoted to developing data processing systems that perform functions normally associated with human intelligence, such as reasoning, learning, and self-improvement (ISO/IEC 2382:2015 Information technology -- Vocabulary)


ASIC. (1) application specific integrated circuit (ISO/IEC/IEEE 24765d:2015)


ask. (1) combination of a specific activity; a demanded execution time, defined by a specific timeliness function; a specific task mode (ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.19)


ASO. (1) Application Service Object (ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)


aspect. (1) special consideration within product line engineering process groups and tasks to associate specialized methods and tools (ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.7) (2) special consideration within product line engineering process groups and tasks with which specialized methods and tools can be associated (ISO/IEC 26553:2018 Information technology-Software and systems engineering- Tools and methods for product line realization, 3.6) (3) special consideration within product line engineering process groups and tasks to which one can associate specialized methods and tools (ISO/IEC 26554:2018 Information technology--Software and systems engineering-Tools and methods for product line testing, 3.4)


ASR. (1) alternative systems review (IEEE 15288.2:2014 IEEE Standard for Technical Reviews and Audits on Defense Programs, 3.2)


assemble. (1) to translate a computer program expressed in an assembly language into its machine language equivalent (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) process of constructing from parts one or more identified pieces of software (IEEE 1517-2010 IEEE Standard for Information Technology--System and software life cycle processes--Reuse processes, 3) (3) activities for combining and connecting implemented system elements or aggregates to support specific goals, i.e. integration, verification, validation, manufacturing, and production (ISO/IEC TS 24748-6:2016 Systems and software engineering--Life cycle management--Part 6: System integration engineering, 3.1.3) See Also: compile, disassemble, interpret


assemble-and-go. (1) operating technique in which there are no stops between the assembling, linking, loading, and execution of a computer program (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


assembled origin. (1) address of the initial storage location assigned to a computer program by an assembler, a compiler, or a linkage editor (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: loaded origin, offset (1), starting address


assembler. (1) computer program that translates programs expressed in assembly language into their machine language equivalents (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: absolute assembler, compiler, cross-assembler, interpreter, relocating assembler


assembly code. (1) computer instructions and data definitions expressed in a form that can be recognized and processed by an assembler (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: assembler code See Also: compiler code, interpretive code, machine code


assembly language. (1) programming language that corresponds closely to the instruction set of a given computer, allows symbolic naming of operations and addresses, and usually results in a one-to-one translation of program instructions into machine instructions (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: assembler language, low-level language, second-generation language See Also: fifth-generation language, fourth-generation language, high order language, machine language.


assertion. (1) logical expression specifying a program state that must exist or a set of conditions that program variables must satisfy at a particular point during program execution. (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) function or macro that complains loudly if a design assumption on which the code is based is not true (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: Types include input assertion, loop assertion, output assertion. See Also: invariant, proof of correctness


assessment. (1) action of applying specific documented criteria to a specific software module, package or product for the purpose of determining acceptance or release of the software module, package or product (ISO/IEC 14102:2008 Information Technology - Guideline for the evaluation and selection of CASE tools, 3.1) (2) process that evaluates a person's fulfillment of the requirements of the certification scheme (ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.2)


assessment body. (1) body that performs an assessment (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.1) Note: A body can be an organization or part of an organization that performs the assessment.


assessment constraint. (1) restriction placed on the use of the assessment outputs or on the assessment team's freedom of choice regarding the conduct of the assessment (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.2)


assessment indicator. (1) sources of objective evidence used to support the assessors' judgment in rating process attributes (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.1) Example: work products, practice, or resource


assessment input. (1) information required before a process assessment can commence (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.3)


assessment output. (1) tangible results from an assessment (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.4) See Also: assessment record


assessment participant. (1) individual who has responsibilities within the scope of the assessment (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.5) Example: the assessment sponsor, assessors, and organizational unit members


assessment purpose. (1) statement, provided as part of the assessment input, which defines the reasons for performing the assessment (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.6)


assessment record. (1) orderly, documented collection of information which is pertinent to the assessment and adds to the understanding and verification of the process profiles generated by the assessment (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.7)


assessment scope. (1) definition of the boundaries of the assessment, provided as part of the assessment input, encompassing the boundaries of the organizational unit for the assessment, the processes to be included, the quality level for each process to be assessed, and the context within which the processes operate (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.8)


assessment sponsor. (1) individual or entity, internal or external to the organizational unit being assessed, who requires the assessment to be performed, and provides financial or other resources to carry it out (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.9)


assessment team. (1) one or more individuals who jointly perform a process assessment (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.10)


assessor. (1) individual who participates in the rating of process attributes (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.11)


asset. (1) item, thing, or entity that has potential or actual value to an organization (ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.1) (ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.2) (2) item that has been designed for use in multiple contexts (IEEE 1012-2016 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1.3) (3) item, such as design, specifications, source code, documentation, test suites, or manual procedures, that has been designed for use in multiple contexts (IEEE 1012-2016 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1) (4) anything that has value to a person or organization (ISO/IEC 25010:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--System and software quality models, 4.3.1) Example: requirements documents, source code modules, measurement definitions Note: Physical assets usually refer to equipment, inventory and properties owned by the organization. Physical assets are the opposite of intangible assets, which are non-physical assets, such as leases, brands, digital assets, use rights, licenses, intellectual property rights, reputation or agreements. A grouping of assets referred to as an asset system could also be considered as an asset.


asset base. (1) reusable assets produced from both domain and application engineering (ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.6)


asset life. (1) period from asset creation to asset end-of-life (ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.2)


asset management. (1) coordinated activity of an organization to realize value from assets (ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.3)


asset management plan. (1) documented information that specifies the activities, resources and timescales required for an individual asset, or a grouping of assets, to achieve the organization's asset management objectives (ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.4)


asset management system. (1) management system for asset management whose function is to establish the asset management policy and asset management objectives (ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.5)


asset portfolio. (1) assets that are within the scope of the asset management system (ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.6) Note: A portfolio is typically established and assigned for managerial control purposes. Portfolios for physical assets might be defined by category (e.g. plant, equipment, tools, land). Software portfolios might be defined by software publisher, or by platform (e.g. PC, server, mainframe).


asset proposal. (1) artifact that includes major assets (functional areas and high-level common and variable features of all applications) that can be included in a product line with their quantified costs and benefits, and estimate results (ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.8)


asset scoping. (1) process of identifying the potential domain assets and estimating the returns of investments in the assets (ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.7) Note: Information produced during asset scoping, together with the information produced by product scoping and domain scoping, can be used to determine whether to introduce a product line into an organization.


asset system. (1) set of assets that interact or are interrelated (ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.7)


asset type. (1) grouping of assets having common characteristics that distinguish those assets as a group or class (ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.8) Example: Physical assets, information assets, intangible assets, critical assets, enabling assets, linear assets, information and communications technology (ICT) assets, infrastructure assets, moveable assets.


assignment. (1) for a set of variables, the association of a value (of correct type) to each variable (ISO/IEC/IEEE 24765i:2020) See Also: binding


assignment statement. (1) computer program statement that assigns a value to a variable (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: Y = X - 5 See Also: control statement, declaration, clear, initialize, reset


assist. (1) tester intervention in the form of direct procedural help provided by the test administrator to the test participants in order to allow the test to continue when the participants could not complete the tasks on their own (ISO/IEC 25062:2006 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Common Industry Format (CIF) for usability test reports, 4.12)


assistive technologies. (1) hardware or software that is added to or incorporated within a system that increases accessibility for an individual (ISO/IEC 25062:2006 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Common Industry Format (CIF) for usability test reports, 4.11) Example: Braille displays, screen readers, screen magnification software, and eye tracking devices


association. (1) in UML, a relationship between an actor and a use case that indicates that the actor interacts with the system by means of the use case (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) relationship (binding) between protocol objects (or between a protocol object and an interceptor) that is established independently of the protocol exchanges that support a particular computational interaction (ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 3.3.2)


association management facility. (1) set of service primitives which support the management of an association between protocol objects (ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 3.3.3)


associative class. (1) class introduced to resolve a many-to-many relationship (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.7)


associative entity. (1) entity used to represent a relationship between other entities (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2) Note: An associative entity is used when a relationship does not otherwise provide sufficient mechanisms.


associative entity type. (1) entity type that contains attributes which further describe a many-to-many relationship between two other entity types (ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.6) See Also: entity type


associative literal. (1) literal that denotes an instance in terms of its value (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.8) Note: The form of expression used to state an associative literal is className with propertyName: propertyValue.


assumption. (1) a factor in the planning process that is considered to be true, real, or certain, without proof or demonstration (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


assumption log. (1) a project document used to record all assumptions and constraints throughout the project life cycle (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


assurance. (1) grounds for justified confidence that a claim has been or will be achieved (ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.1.1)


assurance case. (1) 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) (ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.1.3) (2) representation of a claim or claims, and the support for these claims (IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2) Note: 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


assure. (1) to promise or state with certainty by one person to another person or group (IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2) See Also: ensure


asynchronous. (1) pertaining to two or more processes that do not depend upon the occurrence of specific events such as common timing (ISO/IEC 2382:2015 Information technology -- Vocabulary)


asynchronous communication interface adapter (ACIA). (1) functional unit to connect interfaces for asynchronous communications (ISO/IEC/IEEE 24765d:2015)


asynchronous I/O device. (1) I/O device that generates an interrupt after producing some input or generating some output (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


asynchronous I/O device interface task. (1) task that interfaces to an I/O device and is activated by interrupts from that device (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


asynchronous message communication. (1) communication in which a producer task sends a message to a consumer task and does not wait for a response (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: A message queue could build up between the tasks. Syn: loosely coupled message communication


ATL. (1) annotated topic list (ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.2)


atomic type. (1) data type, each of whose members consists of a single, nondecomposable data item (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: primitive type See Also: composite type


atomicity. (1) entity at a given level of abstraction that cannot be subdivided at that level of abstraction (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 6.4)


attached process. (1) process definitions how each asset will be used in application (ISO/IEC 26555:2015 Software and systems engineering--Tools and methods for product line technical management, 3.2)


attack. (1) malicious action or interaction with the system or its environment that has the potential to result in a fault or an error (and thereby possibly in a failure) or an adverse consequence (ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.4.7)


attribute. (1) property associated with a set of real or abstract things that is some characteristic of interest (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.9) (2) inherent property or characteristic of an entity that can be distinguished quantitatively or qualitatively by human or automated means (ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.1) (3) measurable physical or abstract property of an entity (IEEE 1061-1998 (R2004) IEEE Standard for Software Quality Metrics Methodology, 2.1) (4) identifiable association between an object and a value (ISO/IEC 19500-2:2012 Information technology --Object Management Group--Common Object Request Broker Architecture (CORBA)--Part 2: Interoperability, 3.2.2) (5) function from the instances of a class to the instances of the value class of the attribute (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.9) (6) unique item of information about an entity (ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10) (7) single-valued characteristic of an entity or relationship (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2) (8) label that governs the form or shape of the object it is associated with, which, in contrast to an annotation, is typically not shown as text (ISO/IEC 15909-2:2011 Software and system engineering -- High-level Petri nets -- Part 2: Transfer format, 4.1.2) Example: people, objects, places, events, ideas, or combinations of things Note: can refer either to general characteristics such as reliability, maintainability, and usability or to specific features of a software product. An attribute expresses some characteristic that is generally common to the instances of a class. The name of the attribute is the name of the role that the value class plays in describing the class, which can simply be the name of the value class (as long as using the value class name does not cause ambiguity).


attribute name. (1) role name for the value class of the attribute (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.10)


attribute sampling. (1) method of measuring quality that consists of noting the presence (or absence) of some characteristic (attribute) in each of the units under consideration (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


attributed relationship. (1) relationship that has attributes (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)


attributive entity type. (1) entity type that further describes one or more attributes of another entity type (ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.7) See Also: entity


audience. (1) category of users sharing the same or similar characteristics and needs (for example, reason for using the documentation, tasks, education level, abilities, training, experience) (ISO/IEC 26514:2008 Systems and software engineering--requirements for designers and developers of user documentation, 4.6) (2) category of users sharing the same or similar characteristics and needs (for example, purpose in using the documentation, tasks, education level, abilities, training, and experience) that determine the content, structure, and use of the intended documentation (ISO/IEC/IEEE 23026:2015 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 4.2) Note: There can be a number of audiences for a software products documentation (for example, management, data entry, maintenance, engineering, business professionals). See Also: persona


audience research. (1) planned process of interviews of representative users and analysis of interview records and personnel records (ISO/IEC/IEEE 24765a:2011) Note: The purpose of audience research is to determine the abilities, training, experience, limitations, prejudices and preferences of the intended readers of a document.


audit. (1) systematic, independent and documented process for obtaining audit evidence and evaluating it objectively to determine the extent to which audit criteria are fulfilled (ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.9) (ISO/IEC 15288:2008 Systems and software engineering--System life cycle processes, 4.6) (ISO/IEC 29110-2-1:2015 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 2-1: Framework and taxonomy, 4.7) (2) independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria (ISO/IEC/IEEE 12207:2017 Systems and software engineering--Software life cycle processes, 3.1.10) (ISO/IEC/IEEE 15288:2015 Systems and software engineering--System life cycle processes, 4.1.9) (ISO/IEC/IEEE 24748-1:2018 Systems and software engineering--Life cycle management--Part 1: Guidelines for life cycle management, 2.10) (3) systematic, independent, documented process for obtaining records, statements of fact, or other relevant information and assessing them objectively, to determine the extent to which specified requirements are fulfilled (ISO/IEC TR 29110-1:2016 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 1: Overview, 3.7) Note: An audit can be an internal audit (first party) or an external audit (second party or third party), and it can be a combined or integrated audit (combining two or more disciplines). An audit results in a clear indication of whether the audit criteria have been met. Whilst ?audit? applies to management systems, ?assessment? applies to conformity assessment bodies as well as more generally.


audit team. (1) one or more auditors conducting an audit, supported if needed by technical experts (ISO/IEC 29110-2-1:2015 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 2-1: Framework and taxonomy, 4.10) Note: One auditor of the audit team is appointed as the audit team leader. The audit team can include auditors-in-training.


auditee. (1) organization being audited (ISO/IEC 29110-2-1:2015 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 2-1: Framework and taxonomy, 4.8)


auditor. (1) person who conducts an audit (ISO/IEC 29110-2-1:2015 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 2-1: Framework and taxonomy, 4.9)


augmented reality system. (1) view of the physical world that is supplemented by computer-generated text, images, data, or other media (ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.4)


authenticity. (1) degree to which the identity of a subject or resource can be proved to be the one claimed (ISO/IEC 25010:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--System and software quality models, 4.2.6.5)


author check. (1) informal review performed by the author of the work product (ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.2)


authoring environment. (1) toolset used to create, store, and manage content units (ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.5)


authoring language. (1) high-level programming language used to develop courseware for computer-assisted instruction (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: authoring system


authoring system. (1) programming system that incorporates an authoring language (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


authority. (1) the right to apply project resources, expend funds, make decisions, or give approvals. (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


authorization. (1) action indicating that a particular behavior shall not be prevented (ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.6.4) Note: Unlike a permission, an authorization is an empowerment.


automate. (1) to make a process or equipment automatic (ISO/IEC 2382:2015 Information technology -- Vocabulary)


automated systems process. (1) systems or software process that is performed either fully or partially supported by CASE tools (ISO/IEC 15940:2013 Systems and software engineering--Software Engineering Environment Services, 2.2.3, 2.9) Syn: assisted process, assisted software process, assisted systems process, automated process, automated software process


automated verification system. (1) software tool that accepts as input a computer program and a representation of its specification and produces, possibly with human help, a proof or disproof of the correctness of the program (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) software tool that automates part or all of the verification process (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


automatic. (1) pertaining to a process or equipment that, under specified conditions, functions without human intervention (ISO/IEC 2382:2015 Information technology -- Vocabulary)


automation. (1) conversion of processes or equipment to automatic operation, or the results of the conversion (ISO/IEC 2382:2015 Information technology -- Vocabulary)


autonomy-based improvement. (1) self-motivated and self-determined professional process improvement with an understanding of the work (process) objectives, latest technology, and outcomes from product use (ISO/IEC TR 29110-3-4:2015 Systems and software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 3-4: Autonomy-based improvement method, 3.2) (2) motivated professional process improvement with understanding work (process) objectives, technology status quo, and outcomes from product use, not forced by anybody (ISO/IEC 29110-2-1:2015 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 2-1: Framework and taxonomy, 4.11)


availability. (1) ability of a service or service component to perform its required function at an agreed instant or over an agreed period of time (ISO/IEC/IEEE 24765c:2014) (2) degree to which a system or component is operational and accessible when required for use (ISO/IEC 25010:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--System and software quality models, 4.2.5.2) (3) ability of an application object to perform its required function at an agreed instant or over an agreed period of time (ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.7) (4) degree to which an IT service is available to users when needed (ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.4.3) Note: Availability is normally expressed as a ratio or percentage of the time that the service or service component is actually available for use by the customer to the agreed time that the service should be available. Availability is a combination of maturity (which reflects the frequency of failure), fault tolerance and recoverability (which reflect the length of downtime following each failure). This concerns the start and finish (execution) of the application, the processing at the correct times and in the correct order, the execution of incidental processing, the opening times of online processing, and the storage period of files. See Also: error tolerance, fault tolerance, reliability, robustness


BABOK. (1) Business Analysis Book of Knowledge (ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 3.2)


BAC. (1) budget at completion (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


back matter. (1) material that appears at the end of printed documentation, such as an index (ISO/IEC/IEEE 24765a:2011)


back-to-back testing. (1) testing in which two or more variants of a program are executed with the same inputs, the outputs are compared, and errors are analyzed in case of discrepancies (ISO/IEC TR 19759:2016 Software Engineering -- Guide to the Software Engineering Body of Knowledge (SWEBOK), 4.2.2.9) See Also: mutation testing


background. (1) in job scheduling, the computing environment in which low-priority processes or those not requiring user interaction are executed (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: foreground. background processing


background processing. (1) execution of a low-priority process while higher priority processes are not using computer resources, or the execution of processes that do not require user interaction (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: foreground processing


backlog. (1) list of product requirements and deliverables not part of current work, to be prioritized and completed (ISO/IEC/IEEE 24765h:2019) (2) a set of software features awaiting development in a subsequent iteration (Software Extension to the PMBOK(R) Guide Fifth Edition) (3) collection of agile features or stories of both functional and nonfunctional requirements that are typically sorted in an order based on value priority (ISO/IEC/IEEE 26515: 2018 Systems and software engineering: Developing information for users in an agile environment, 3.4)


backout. (1) to undo the effects of a commit (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: often by introducing a new commit that restores things to their previous state


backup. (1) system, component, file, procedure, or person available to replace or help restore a primary item in the event of a failure or externally caused disaster (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) to create or designate a system, component, file, procedure, or person as a replacement (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: back-up


backup and recovery testing. (1) type of reliability testing that measures the degree to which system state can be restored from backup within specified parameters of time, cost, completeness, and accuracy in the event of failure (ISO/IEC/IEEE 29119-1:2013 Software and systems engineering--Software testing--Part 1: Concepts and definitions, 4.3)


backup programmer. (1) assistant leader of a chief programmer team (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: Responsibilities include contributing significant portions of the software being developed by the team, aiding the chief programmer in reviewing the work of other team members, substituting for the chief programmer when necessary, and having an overall technical understanding of the software being developed. See Also: chief programmer


Backus-Naur Form. (1) formal meta-language used for defining the syntax of a language in a textual format (ISO/IEC/IEEE 29119-4:2015 Software and systems engineering -- Software testing -- Part 4: Test techniques, 4.1)


backward pass. (1) a critical path method technique for calculating the late start and late finish dates by working backward through the schedule model from the project end date (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) See Also: schedule network analysis


backward recovery. (1) reconstruction of a file to a given state by reversing all changes made to the file since it was in that state (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) type of recovery in which a system, program, database, or other system resource is restored to a previous state in which it can perform required functions (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: forward recovery


bag. (1) a collection class whose members are unordered but in which duplicates are meaningful (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.11) See Also: list, set


ball grid array (BGA). (1) surface-mounted integrated circuit package with multiple connections in a grid pattern on the bottom surface (ISO/IEC/IEEE 24765c:2014) Note: provides more connections than on packages with connectors on the edges only


bar chart. (1) a graphic display of schedule-related information. In the typical bar chart, schedule activities or work breakdown structure components are listed down the left side of the chart, dates are shown across the top, and activity durations are shown as date-placed horizontal bars. (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) See Also: Gantt chart


base address. (1) address used as a reference point to which a relative address is added to determine the address of the storage location to be accessed (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: indexed address, relative address, self-relative address


base class. (1) relationship between a template class CB of instances of B and template class CA of instances of A, where template A is an incremental modification of template B (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.24) See Also: derived class


base functional component (BFC). (1) an elementary unit of functional user requirements defined by and used by an FSM method for measurement purposes (ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.1) (ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.8) (ISO/IEC 14143-1:2007 Information technology--Software measurement--Functional size measurement; Part 1: Definition of concepts, 3.1) Example: A functional user requirement "Maintain Customers" consists of the following BFCs: "Add a new customer", "Report Customer Purchases", and "Change Customer Details". A collection of logically related business data is maintained by the software as "Customer Details". Syn: functional service


base functional component type (BFC type). (1) defined category of Base Functional Component (ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.2)


base measure. (1) measure defined in terms of an attribute and the method for quantifying it (ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.3) Note: A base measure is functionally independent of other measures.


base practice (BP). (1) activity that, when consistently performed, contributes to achieving a specific process purpose (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.2)


base standard. (1) approved International Standard or Telecommunication Standardization Sector of the International Telecommunications Union (ITU-T) Recommendation (ISO/IEC TR 29110-1:2016 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 1: Overview, 2.5)


base value. (1) input parameter value used in base choice testing that is normally selected based on being a representative or typical value for the parameter (ISO/IEC/IEEE 29119-4:2015 Software and systems engineering -- Software testing -- Part 4: Test techniques, 4.3) Syn: base choice


baseline. (1) 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 (ISO/IEC/IEEE 12207:2017 Systems and software engineering--Software life cycle processes, 3.1.11) (ISO/IEC/IEEE 15288:2015 Systems and software engineering--System life cycle processes, 4.1.10) (2) formally controlled and maintained set of data that serves as the basis for defining change (IEEE 15288.1:2014 IEEE Standard for Application of Systems Engineering on Defense Programs, 3.1) (3) agreement or result designated and fixed at a given time, from which changes require justification and approval (IEEE 1012-2016 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1) (4) snapshot of the state of a service or individual configuration items at a point in time (5) approved version of a configuration item, regardless of media, formally designated and fixed at a specific time during the configuration item's life cycle (ISO/IEC/IEEE 24748-1:2018 Systems and software engineering--Life cycle management--Part 1: Guidelines for life cycle management, 2.11) (6) the approved version of a work product that can be changed only through formal change control procedures and is used as a basis for comparison (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) (7) [verb] to establish and approve a set of data (IEEE 15288.1:2014 IEEE Standard for Application of Systems Engineering on Defense Programs, 3.1) Note: Some baselines are project deliverables while others provide the basis for further work. A baseline, together with all approved changes to the baseline, represents the current approved configuration. The term is thus used to refer to a particular version of a software configuration item that has been agreed on, e.g., as a stable base for further development or to mark a specific project milestone. In either case, any new baseline is agreed through the project's agreed change control procedures.


baseline design. (1) system design that has been agreed on by all stakeholders interested in the system development (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


baseline document. (1) system or software document that defines a work product that has been placed under configuration management (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: design specifications, requirements specifications, system specifications


baseline function point count. (1) application function point count taken of the functionality at a point in time, from which changes can be measured (ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)


baseline management. (1) in configuration management, the application of technical and administrative direction to designate the documents and changes to those documents that formally identify and establish baselines at specific times during the life cycle of a configuration item (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


basic engineering object. (1) engineering object that requires the support of a distributed infrastructure (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.1) Example: null Syn: BEO


basic flow. (1) part of a use case that describes its most common implementation (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: The basic flow is written assuming that no errors or alternatives exist. Syn: basic path, happy day scenario


basic interworking facility. (1) a set of service primitives which have a direct correspondence with computational signals which model computational operations (ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 3.3.4)


basic maturity level. (1) lowest level of achievement in a scale of organizational process maturity (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.3)


basic process set. (1) set of processes, which ensure the achievement of the basic maturity level (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.4)


basic profile. (1) profile targeted at VSEs developing a single application by a single work team (ISO/IEC 29110-2-1:2015 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 2-1: Framework and taxonomy, 4.14)


basic symbol. (1) symbol used when the precise nature or form of, for example, the process or data media is not known or when it is not necessary to depict the actual medium (ISO 5807:1985 Information processing -- Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts, 3.1)


basis of estimates. (1) supporting documentation outlining the details used in establishing project estimates such as assumptions, constraints, level of detail, ranges, and confidence levels (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) Syn: basis of estimate


basis set. (1) set of objects used to create a multiset (ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 2.1.4)


batch. (1) pertaining to a system or mode of operation in which inputs are collected and processed all at one time, rather than being processed as they arrive, and a job, once started, proceeds to completion without additional input or user interaction (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: conversational, interactive, online, real time


bathtub curve. (1) graph of the number of failures in a system or component as a function of time (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: The name is derived from the usual shape of the graph: a period of decreasing failures (the early-failure period), followed by a relatively steady period (the constant-failure period), followed by a period of increasing failures (the wearout-failure period).


BCWP. (1) budgeted cost of work performed (ISO/IEC/IEEE 24765c:2014)


BCWS. (1) budgeted cost of work scheduled (ISO/IEC/IEEE 24765c:2014)


behavior. (1) observable activity of a system, measurable in terms of quantifiable effects on the environment whether arising from internal or external stimulus (2) of an object, a collection of actions with a set of constraints on when they may occur (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.7) (3) peculiar reaction of a thing under given circumstances (4) aspect of an instance's specification that is determined by the state-changing operations it can perform (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.12) Syn: behaviour


behavioral compatibility. (1) identical behavior of two objects, such that one object can replace the other with respect to a set of criteria without the environment being able to notice the difference in the objects' behavior on the basis of the set of criteria (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.4)


benchmark. (1) standard against which results can be measured or assessed (ISO/IEC 25010:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--System and software quality models, 4.3.2) (2) procedure, problem, or test that can be used to compare systems or components to each other or to a standard (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) reference point against which comparisons can be made (ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 2.1)


benchmarking. (1) activity of comparing objects of interest to each other or against a benchmark to evaluate characteristic(s) (ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 2.2) (2) the comparison of actual or planned practices, such as processes and operations, to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) Note: In the context of ISO/IEC 29155, the object of interest is IT project performance, and the characteristic is a particular aspect of an IT project such as productivity.


benchmarking analyst. (1) person or organization that conducts benchmarking activity (ISO/IEC 29155-3:2015 Systems and software engineering--Information technology project performance benchmarking framework--Part 3: Guidance for reporting)


benchmarking experience base. (1) information store that contains the evaluation of the information products and the benchmarking activity, as well as any lessons learned during benchmarking and analysis (ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 2.3)


benchmarking method. (1) logical sequence of general steps to describe the process of comparing one or more attributes against a reference attribute with respect to a specified scale (ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 2.4)


benchmarking report. (1) document of the results of an instance of benchmarking (ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 3.7) Note: Document usually consists of various formats (e.g. textual descriptions, numeric values, statistical charts and tables), and is exchanged via various media (e.g. electronic documents, electronic data set, printed documents, and embedded data within specific computer software).


benchmarking repository. (1) organized and persistent data storage which is designated for benchmarking (ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 3.8)


benchmarking user. (1) person or organization that utilizes the outcome of benchmarking (ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 2.5)


benefit cost analysis. (1) in not-for-profit decision analysis, evaluating the desirability of an alternative on the ratio of the net benefits to the population to the net costs to the sponsor (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


BEO. (1) Basic Engineering Object (ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview) (ISO/IEC 19793:2015 Information technology -- Open Distributed Processing -- Use of UML for ODP system specifications, 4)


beta test. (1) second stage of testing when a product is in limited production use (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: often performed at a customer site See Also: alpha testing


BFC. (1) base functional component (ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.1) (ISO/IEC 14143-1:2007 Information technology--Software measurement--Functional size measurement; Part 1: Definition of concepts, 4)


BFC class. (1) defined group of BFC types (ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, 3.1)


BFC Type. (1) a defined category of BFCs (ISO/IEC 14143-1:2007 Information technology--Software measurement--Functional size measurement; Part 1: Definition of concepts, 3.2) Example: 'External Inputs', 'External Outputs' and 'Logical Transactions', and data stores such as 'Internal Logical Files'


BGA. (1) ball grid array (ISO/IEC/IEEE 24765c:2014)


bidder conference. (1) the meetings with prospective sellers prior to the preparation of a bid or proposal to ensure all prospective vendors have a clear and common understanding of the procurement. Also known as contractor conferences, vendor conferences, or pre-bid conferences (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


bidirectional traceability. (1) association among two or more logical entities that is discernible in either direction (to and from an entity) (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: requirements traceability


big-bang testing. (1) type of integration testing in which software elements, hardware elements, or both are combined all at once into an overall system, rather than in stages (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


bill of materials (BOM). (1) documented formal hierarchical tabulation of the physical assemblies, subassemblies, and components needed to fabricate a product (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


binary digit (bit). (1) unit of information that can be represented by either a zero or a one (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) element of computer storage that can hold a unit of information as in (1) (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) numeral used to represent one of the two digits in the binary numeration system; zero (0) or one (1) (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


bind. (1) to assign a value to an identifier (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: to assign a value to a parameter or to assign an absolute address to a symbolic address in a computer program See Also: dynamic binding, static binding


binder. (1) engineering object in a channel, which maintains a distributed binding between interacting basic engineering objects (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.10)


binding. (1) contractual context resulting from a given establishing behavior (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.5.2) (2) task to make a decision on relevant variants, which will be application assets, from domain assets using the domain variability model and from application assets using the application variability model (ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.8) (3) task for making a decision on relevant variants using a domain variability model and decision tables (ISO/IEC 26557:2016 Software and systems engineering -- Methods and tools for variability mechanisms in software and systems product line, 3.3) See Also: assignment


binding behavior. (1) establishing behavior between two or more interfaces, and hence between their supporting objects (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.5.1)


binding endpoint identifier. (1) identifier, in the naming context of a capsule, used by a basic engineering object to select one of the bindings in which it is involved, for the purpose of interaction (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.15) Example: a memory address (for a data structure representing an engineering interface) Note: The same form of binding endpoint identifier can be used, whether the binding involved is either local or distributed.


binding object. (1) computational object which supports a binding between a set of other computational objects (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.14)


binding precondition. (1) set of conditions required for the successful execution of a binding behavior (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.5.3)


binding time. (1) moment of variability resolution (ISO/IEC 26555:2015 Software and systems engineering--Tools and methods for product line technical management, 3.3) Note: The choice of binding time is independent from variability modelling. It is the consequence of decisions made from requirements through run time. Demands for flexibility and the support of tools allow late binding times or even the use of variable binding times.


binding time decision. (1) selection for variability defined in platforms in accordance with the functional distinction between variability in time and variability in space (ISO/IEC 26557:2016 Software and systems engineering -- Methods and tools for variability mechanisms in software and systems product line, 3.5)


binding time of variability. (1) stage when the value of variability is determined (ISO/IEC 26553:2018 Information technology-Software and systems engineering- Tools and methods for product line realization, 3.7)


bit. (1) either of the digits 0 or 1 when used in the binary numeration system (ISO/IEC 2382:2015 Information technology -- Vocabulary) (2) binary digit (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) built-in test (IEEE 15288.2:2014 IEEE Standard for Technical Reviews and Audits on Defense Programs, 3.2) Syn: BIT


bit steering. (1) microprogramming technique in which the meaning of a field in a microinstruction is dependent on the value of another field in the microinstruction (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: immediate control See Also: residual control, two-level encoding


black box. (1) system or component whose inputs, outputs, and general function are known but whose contents or implementation are unknown or irrelevant (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (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 (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: glass box


block. (1) group of contiguous storage locations, computer program statements, records, words, characters, or bits that are treated as a unit (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) to form a group (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: block-structured language, delimiter


block diagram. (1) diagram of a system in which the principal parts or functions are represented by blocks connected by lines that show the relationships of the blocks (ISO/IEC 2382:2015 Information technology -- Vocabulary) (2) diagram of a system, computer, or device in which the principal parts are represented by suitably annotated geometrical figures to show both the functions of the parts and their functional relationships (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: configuration diagram, system resources chart See Also: box diagram, bubble chart, flowchart, graph, input-process-output chart, structure chart







block-structured language. (1) design or programming language in which sequences of statements, called blocks, are defined, usually with begin and end delimiters, and variables or labels defined in one block are not recognized outside that block (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: Ada, ALGOL, PL/I See Also: structured programming language


blocking factor. (1) number of records, words, characters, or bits in a block (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


BM. (1) business manager (ISO/IEC TR 29110-5-6-3:2019 Systems and software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 5-6-3: Systems engineering: Management and engineering guide: Generic profile group: Intermediate profile, 4.3)


BMP. (1) bitmap image file (ISO/IEC/IEEE 26531:2015 Systems and software engineering -- Content management for product lifecycle, user and service management documentation, 5)


BMT. (1) Bench Mark Test (ISO/IEC 14102:2008 Information Technology - Guideline for the evaluation and selection of CASE tools, 8.2)


body metadata. (1) elements in the body of an HTML document providing administrative or navigational facilities for the user or administrator (ISO/IEC/IEEE 23026:2015 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 4.3)


body of knowledge. (1) collection of knowledge items or areas generally agreed to be essential to understanding a particular subject (ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.11) Syn: BOK


BOK. (1) body of knowledge (ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.11)


BOM. (1) bill of materials (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


Boolean expression. (1) expression that evaluates to true or false (ISO/IEC/IEEE 24765i:2020)


Boolean signature. (1) signature where one of the sorts is Bool, corresponding to the carrier Boolean in any associated algebra, and one of the constants is true sub Bool, corresponding to the value true in the algebra (ISO/IEC/IEEE 24765i:2020)


boot. (1) to initialize a computer system by clearing memory and reloading the operating system (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: derived from bootstrap


boot mode. (1) initialized mode of program operations when a computer is turned on (ISO/IEC/IEEE 24765d:2015)


bootstrap. (1) short computer program that is permanently resident or easily loaded into a computer and whose execution brings a larger program, such as an operating system or its loader, into memory (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) to use a program to bring up a larger program, such as an operating system (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: null


bootstrap loader. (1) short computer program used to load a bootstrap (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


bottom-up. (1) pertaining to an activity that starts with the lowest-level components of a hierarchy and proceeds through progressively higher-levels (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) pertaining to a method or procedure that starts at the lowest level of abstraction and proceeds towards the highest level (ISO/IEC 2382:2015 Information technology -- Vocabulary) Example: bottom-up design, bottom-up testing See Also: top-down. critical piece first


bottom-up design. (1) design approach in which low-level pieces of a system are combined into an overall design (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) process of designing a system by identifying low-level components, designing each component separately, and then designing a structure to integrate the low-level components into larger and larger subsystems until the design is finished (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


bottom-up estimating. (1) a method of estimating project duration or cost by aggregating the estimates of the lower-level components of the work breakdown structure (WBS) (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


boundary. (1) conceptual interface between the software under study and its users (ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.9) (ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, 3.2) (2) conceptual interface between the software being measured and its functional users (ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.3) Note: The boundary provides the measurement analyst(s) with a solid delimiter to distinguish, without ambiguity, what is included inside the measured software from what is part of the measured software's operating environment. The boundary defines what is external to the application; it indicates the border between the software being measured and the user; it acts as a ?membrane? through which data processed by transactions pass into and out of the application; it is dependent on the user?s external business view of the application; it is independent of non-functional and/or implementation considerations. The boundary is identical when assessing the functional size and the non-functional size. Syn: application boundary, software boundary


boundary arrow. (1) arrow with one end (source or use) not connected to any box in a diagram (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.14) See Also: internal arrow


boundary ICOM code. (1) ICOM code that maps an untunneled boundary arrow in a child diagram to an arrow attached to the parent box that is detailed by that diagram (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.15)


boundary value. (1) data value that corresponds to a minimum or maximum input, internal, or output value specified for a system or component (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: stress testing


box. (1) rectangle containing a box name, a box number, and possibly a box detail reference and representing a function in a diagram (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.16)


box detail reference. (1) square enclosure encompassing a box number, which indicates that the box is decomposed or detailed by a child diagram (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.17)


box diagram. (1) control flow diagram consisting of a rectangle that is subdivided to show sequential steps, if-then-else conditions, repetition, and case conditions (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: Chapin chart, Nassi-Shneiderman chart See Also: block diagram, bubble chart, flowchart, graph, input-process-output chart, program structure diagram, structure chart







box ICOM code. (1) ICOM code that maps a tunneled boundary arrow to an arrow attached to some ancestral box (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.18)


box name. (1) verb or verb phrase placed inside a box that names the modeled function (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.19) Note: A box takes as its box name the function name of the function represented by the box. See Also: function name


box number. (1) single digit (0, 1, 2, ..., 9) placed in the lower right corner of a box to uniquely identify that box in a diagram (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.20) Example: null Note: The only box that can be numbered 0 is the box that represents the A0 function in A-0 and A-1 context diagrams.


BP. (1) base practice (ISO/IEC TR 29110-3-1:2015 Systems and software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 3-1: Assessment Guide, 4.2)


brainstorming. (1) 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 (ISO/IEC/IEEE 24765h:2019)


branch. (1) computer program construct in which one of two or more alternative sets of program statements is selected for execution (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) point in a computer program at which one of two or more alternative sets of program statements is selected for execution (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) junction at which a root arrow segment (going from source to use) divides into two or more arrow segments (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.21) (4) to perform the selection in (1) (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (5) any of the alternative sets of program statements in (1) (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (6) set of evolving source file versions (ISO/IEC TR 19759:2016 Software Engineering -- Guide to the Software Engineering Body of Knowledge (SWEBOK), 6.1.3) (7) deviation from the main development line for a configuration item, which allows different persons to work on the same item at the same time (ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.3) 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. It can denote unbundling of arrow meaning, i.e., 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. See Also: case, jump, go to, if-then-else


branch testing. (1) testing designed to execute each outcome of each decision point in a computer program (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: path testing, statement testing


branching. (1) method of development in which a set of components is duplicated so the components may be modified in parallel and optionally synchronized at a later time (ISO/IEC/IEEE 26531:2015 Systems and software engineering -- Content management for product lifecycle, user and service management documentation, 4,2)


breadcrumb trail. (1) navigational aid with a displayed series of hyperlinks which lead from the home page to the current page, allowing the user to return to previously viewed pages (ISO/IEC/IEEE 23026:2015 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 4.4)


break-even analysis. (1) analysis of two or more objective functions to find where, if at all, they have the same value (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


breakpoint. (1) point in a computer program at which execution can be suspended to permit manual or automated monitoring of program performance or results (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: Types include code breakpoint, data breakpoint, dynamic breakpoint, epilog breakpoint, programmable breakpoint, prolog breakpoint, static breakpoint. A breakpoint is said to be set when both a point in the program and an event that will cause suspension of execution at that point are defined; it is said to be initiated when program execution is suspended.


browser. (1) application allowing a person to retrieve and read hypertext, to view the contents of hypertext nodes (Web pages), to navigate from one Web page to another, and to interact with the content, such as changing the visual appearance of the displayed content (ISO/IEC/IEEE 23026:2015 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 4.5)


BRS. (1) business requirements specification (ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.2)


bubble chart. (1) data flow, data structure, or other diagram in which entities are depicted with circles (bubbles) and relationships are represented by links drawn between the circles (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: block diagram, box diagram, flowchart, graph, input-process-output chart, structure chart







buddy check. (1) informal review performed independently by a colleague of the author (ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.3) See Also: peer review


budget. (1) the approved estimate for the project or any work breakdown structure component or any schedule activity (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) Note: often used also to refer to work effort as well as, or instead of, money. See Also: estimate


budget at completion (BAC). (1) the sum of all the budgets established for the work to be performed (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


buffer. (1) device or storage area used to store data temporarily to compensate for differences in rates of data flow, time of occurrence of events, or amounts of data that can be handled by the devices or processes involved in the transfer or use of the data (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) routine that accomplishes the objectives in (1) (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) to allocate, schedule, or use devices or storage areas as in (1) (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


build. (1) operational version of a system or component that incorporates a specified subset of the capabilities that the final product will provide (IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1) (ISO/IEC 19506:2012 Information technology -- Object Management Group Architecture-Driven Modernization (ADM) -- Knowledge Discovery Meta-Model (KDM), 4) (2) process of generating (archiving) an executable and testable system from source versions or baselines (IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1) (ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.4) (3) to perform the steps required to produce an instance of the product (IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1) Note: In software, this means processing source files to derive target files. In hardware, this means assembling a physical object. The build needs to compile and link the various versions in the correct order. The build tools can be integrated into a configuration management tool.


build process. (1) process of transforming project code base into usable applications (ISO/IEC 19506:2012 Information technology -- Object Management Group Architecture-Driven Modernization (ADM) -- Knowledge Discovery Meta-Model (KDM), 4)


built-in class. (1) class that is a primitive in the IDEF1X metamodel (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.13) Example: null


built-in random access memory (RAM). (1) RAM embedded in a microcontroller unit (MCU) chip (ISO/IEC/IEEE 24765e:2015) Syn: built-in RAM


built-in read only memory. (1) read-only memory embedded in a microcontroller unit (MCU) chip (ISO/IEC/IEEE 24765d:2015) Syn: built-in ROM


bundle. (1) grouping of products which is the result of a marketing/licensing strategy to sell entitlements to multiple products as one purchased item (ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.5) (2) arrow segment that collects multiple meanings into a single construct or abstraction, i.e., an arrow segment that represents an object type set that includes more than one object type (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.22) (3) to combine separate arrow meanings into a composite arrow meaning, expressed by joining arrow segments, i.e., the inclusion of multiple object types into an object type set (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.22) Note: A bundle can be referred to as a suite, if the products are closely related and typically integrated (such as an office suite containing a spreadsheet, word processor, presentation and other related items). Bundles can also refer to software titles that are less closely related such as a game, a virus scanner and a utility bundled together with a new computer, or to groups of entitlements, such as multiple entitlements for a backup software product.


burndown. (1) an indicator of the work completed and an estimate of remaining work to be completed or remaining effort needed to complete a product development iteration cycle. Work is measured as all work done to deliver story points, stories, features, functions, function points, user stories, use cases, or requirements during a product development iteration. (Software Extension to the PMBOK(R) Guide Fifth Edition) See Also: burnup


burndown chart. (1) graph that represents the work remaining to do on a project (ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.6)


burndown rate. (1) the number of software story points, features, functions, user stories, use cases, or requirements completed per work unit (week or iteration) (Software Extension to the PMBOK(R) Guide Fifth Edition) See Also: velocity


burnup. (1) an indicator of the number of story points, features, functions, user stories, use cases, or requirements completed and the work remaining or remaining effort needed to complete a product development iteration cycle. Work is measured as all work done to deliver story points, features, functions, user stories, use cases, or requirements during a product development iteration. (Software Extension to the PMBOK(R) Guide Fifth Edition) Syn: burn-up See Also: burndown


bus. (1) data communication path in a computer or system (ISO/IEC/IEEE 24765c:2014)


business case. (1) a documented economic feasibility study used to establish validity of the benefits of a selected component lacking sufficient definition and that is used as a basis for the authorization of further project management activities (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


business information management. (1) domain responsible for all of the tasks and activities that are aimed at supporting the end users in the use of the application and at acting as the customer of the IT organizations (ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.8) Note: Note 1 to entry: Business information management represents the business as the customer organization or client of the application management and IT infrastructure management organizations in maintaining the functionality of the information provisioning and the information systems. It is the demand side of the information provisioning. Note 2 to entry: An information system may have non-automated elements such as forms and user guides. Those elements are usually maintained by the business information management organization.


business objective. (1) strategy designed by senior management to ensure an organization's continued existence and enhance its profitability, market share, and other factors influencing the organization's success (ISO/IEC TR 29110-5-1-4:2018 Software and systems engineering-Lifecycle profiles for very small entities (VSEs)-Part 5-1-4: Software engineering: Management and engineering guidelines: Generic profile group: Advanced profile, 3.5)


business process. (1) partially ordered set of enterprise activities that can be executed to achieve some desired end-result in pursuit of a given objective of an organization (ISO/IEC/IEEE 12207:2017 Systems and software engineering--Software life cycle processes, 3.1.12)


business requirements specification (BRS). (1) structured collection of the requirements (business or mission problem or opportunity definition, concepts, and required conditions of solutions) of the business or mission and its relation to the external environment (ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 3.1.4)


business value. (1) a documented economic feasibility study used to establish validity of the benefits of a selected component lacking sufficient definition and that is used as a basis for the authorization of further project management activities. (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


busy. (1) pertaining to a system or component that is operational, in service, and in use (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: down, idle, up


busy time. (1) in computer performance engineering, the period of time during which a system or component is operational, in service, and in use (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: null Note: operational, in service, and in use See Also: down time, idle time, set-up time, up time


byte. (1) group of adjacent binary digits operated upon as a unit and usually shorter than a computer word (frequently connotes a group of eight bits) (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) element of computer storage that can hold a group of bits as in (1) (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) string that consists of a number of bits, treated as a unit, and usually representing a character or a part of a character (ISO/IEC 2382:2015 Information technology -- Vocabulary)


C4I. (1) command, control, communications, computer, and intelligence (IEEE 15288.2:2014 IEEE Standard for Technical Reviews and Audits on Defense Programs, 3.2)


cache. (1) temporary storage in computer memory, to improve operations by having frequently used data readily available for retrieval (ISO/IEC/IEEE 24765c:2014) (2) RAM with very high operating speed used for data storage within a processor (ISO/IEC/IEEE 24765c:2014)


CAD. (1) Computer Aided Design (ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)


cadence. (1) frequency of performing a periodic activity, such as incremental product release (Software Extension to the PMBOK(R) Guide Fifth Edition)


CAI. (1) critical application item (IEEE 15288.1:2014 IEEE Standard for Application of Systems Engineering on Defense Programs, 3.2)


calculator. (1) device that is suitable for performing arithmetic operations, but that requires human intervention to alter its stored program, if any, and to initiate each operation or sequence of operations (ISO/IEC 2382:2015 Information technology -- Vocabulary) Note: A calculator performs some of the functions of a computer, but usually operates only with frequent human intervention.


calendar unit. (1) smallest unit of time used in scheduling a project (ISO/IEC/IEEE 24765c:2014) Note: Calendar units are generally in hours, days, or weeks, but can also be in quarter years, months, shifts, or even in minutes.


call. (1) transfer of control from one software module to another, usually with the implication that control will be returned to the calling module (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) computer instruction that transfers control from one software module to another as in (1) and often specifies the parameters to be passed to and from the module (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) to transfer control from one software module to another as in (1) and, often, to pass parameters to the other module (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (4) request for service(s) or action(s) with respect to an application or a related service (ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.9) Example: null Note: A call might concern a request for service, information or advice; disruption or error reporting (incident); request for change; assignment (for instance an instruction to start an off-schedule production run); and complaint. See Also: go to


call arrow. (1) arrow that enables the sharing of detail between IDEF0 models (linking them together) or within an IDEF0 model (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.23) Note: The tail of a call arrow is attached to the bottom side of a box. One or more page references are attached to a call arrow.


call by name. (1) method for passing parameters, in which the calling module provides to the called module a symbolic expression representing the parameter to be passed, and a service routine evaluates the expression and provides the resulting value to the called module (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: null Note: Because the expression is evaluated each time its corresponding formal parameter is used in the called module, the value of the parameter can change during the execution of the called module. See Also: call by reference, call by value


call by reference. (1) a method for passing parameters, in which the calling module provides to the called module the address of the parameter to be passed (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: With this method, the called module has the ability to change the value of the parameter stored by the calling module. Syn: call by address, call by location See Also: call by name, call by value


call by value. (1) method of passing parameters, in which the calling module provides to the called module the actual value of the parameter to be passed (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: With this method, the called module cannot change the value of the parameter as stored by the calling module. See Also: call by name, call by reference


call graph. (1) diagram that identifies the modules in a system or computer program and shows which modules call one another (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: The result is not necessarily the same as that shown in a structure chart. Syn: call tree, tier chart See Also: structure chart, control flow diagram, data flow diagram, data structure diagram, state diagram







call list. (1) ordered list of arguments used in a call to a software module (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


call reference. (1) page reference attached to a call arrow (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.24)


called diagram. (1) decomposition diagram invoked by a calling box and identified by a page reference attached to a call arrow (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.25)


calling box. (1) box that is detailed by a decomposition diagram that is not the box's child diagram (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.26) Note: A call arrow is attached to the bottom of a calling box.


calling sequence. (1) sequence of computer instructions and, possibly, data necessary to perform a call to another module (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


CAN. (1) controller area network (ISO/IEC/IEEE 24765d:2015)


candidate. (1) applicant who has fulfilled prerequisites and has been admitted to the certification process (ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3,3)


candidate FSM method. (1) documented software size measurement method submitted for conformity evaluation (ISO/IEC 14143-2:2011 Information technology -- Software measurement -- Functional size measurement -- Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1, 3.1)


candidate key. (1) attribute, or combination of attributes, of an entity for which no two instances agree on the values (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.14) Note: [key style]


capability. (1) measure of capacity and the ability of an entity (system, person or organization) to achieve its objectives (ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.10)


capability maturity model. (1) model that contains the essential elements of effective processes for one or more disciplines and describes an evolutionary improvement path from ad hoc, immature processes to disciplined, mature processes with improved quality and effectiveness (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


capable process. (1) process that can satisfy specified product quality, service quality, and process-performance objectives (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: stable process, standard process, statistically managed process


capacity. (1) degree to which the maximum limits of a product or system parameter meet requirements (ISO/IEC 25010:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--System and software quality models, 4.2.2.3) Note: Parameters can include the number of items that can be stored, the number of concurrent users, the communication bandwidth, throughput of transactions, and size of database.


capacity testing. (1) type of performance efficiency testing conducted to evaluate the level at which increasing load (of users, transactions, data storage, etc.) compromises a test item's ability to sustain required performance (ISO/IEC/IEEE 29119-1:2013 Software and systems engineering--Software testing--Part 1: Concepts and definitions, 4.5)


capital expenditure. (1) spending by an enterprise to acquire tangible infrastructure or facilities items, such as furniture, computers, and the like (ISO/IEC/IEEE 24765a:2011) Note: does not include acquisition of consumable supplies or of items to be included in finished products for sale


capsule. (1) configuration of engineering objects forming a single unit for the purpose of encapsulation of processing and storage (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.4) Example: a virtual machine (e.g. a process)


capsule manager. (1) engineering object which manages the engineering objects in a capsule (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.5)


CARD. (1) cost analysis requirements description (IEEE 15288.2:2014 IEEE Standard for Technical Reviews and Audits on Defense Programs, 3.2)


cardinality. (1) constraint on the number of entity instances that are related to the subject entity through a relationship (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2) (2) specification of how many instances of a first class can or are required to exist for each instance of a second (not necessarily distinct) class, and how many instances of a second class can or are required to exist for each instance of a first class (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.15) Note: For each direction of a relationship, the cardinality can be constrained. See Also: cardinality constraint


cardinality constraint. (1) constraint that limits the number of instances that can be associated with each other in a relationship (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.16) (2) constraint that limits the number of members in a collection (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.16) See Also: cardinality


carrier. (1) set of a many-sorted algebra (ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.4)


case. (1) single-entry, single-exit multiple-way branch that defines a control expression, specifies the processing to be performed for each value of the control expression, and returns control in all instances to the statement immediately following the overall construct (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) Computer Aided Software Engineering (ISO/IEC 14102:2008 Information Technology - Guideline for the evaluation and selection of CASE tools, 4) Syn: multiple exclusive selective construct See Also: go to, jump, if-then-else. multiple inclusive selective construct







CASE needs. (1) organizational requirements which are met by CASE tool characteristics (ISO/IEC TR 14471:2007 Information technology--Software engineering--Guidelines for the adoption of CASE tools, 2.1.3) Note: These characteristics are detailed in ISO/IEC 14102:1995. They include management process, development process, maintenance, documentation, configuration management, quality assurance, verification, validation, environment needs, CASE tool integrability, quality characteristics, acquisition needs, implementation needs, support indicators, and certification requirements.


CASE tool. (1) software product that can assist software and system engineers by providing automated support for software and system engineering life-cycle activities (ISO/IEC 15940:2013 Systems and software engineering--Software Engineering Environment Services, 2.3) (2) software product that can assist software engineers by providing automated support for software life-cycle activities (ISO/IEC 14102:2008 Information Technology - Guideline for the evaluation and selection of CASE tools, 3.2) Note: A CASE tool can provide support in only selected functional areas or in a wide variety of functional areas.


cast. (1) to treat an object of one type as an object of another type (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.17) See Also: coerce


catastrophic failure. (1) failure of critical software (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


categorization. (1) specific way to allocate a target system into a category (ISO/IEC TR 12182:2015 Systems and software engineering--Framework for categorization of IT systems and software, and guide for applying it, 3.5) See Also: generalization


categorization scheme. (1) orderly combination of views and categories related to software (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


categorization space. (1) universal set of systems and software which has one or more classification axes as its individual dimension, by which stakeholder's concerns on categorization are expressed (ISO/IEC TR 12182:2015 Systems and software engineering--Framework for categorization of IT systems and software, and guide for applying it, 3.6)


category. (1) specifically defined division or grouping of software based upon one or more attributes or characteristics (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) subset of categorization space, which the stakeholders are interested in, specified using a combination of one or more equivalence classes (ISO/IEC TR 12182:2015 Systems and software engineering--Framework for categorization of IT systems and software, and guide for applying it, 3.9)


category entity. (1) entity whose instances represent a subtype or subclassification of another entity (generic entity) (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.21) Note: [key style] See Also: subclass, subtype


causal analysis. (1) analysis of a defect to determine its cause (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


cause and effect diagram. (1) a decomposition technique that helps trace an undesirable effect back to its root cause (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) Syn: fishbone diagram


caution. (1) hazardous situation which, if not avoided, can result in minor or moderate injury (ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.5) (2) advisory in software user documentation that performing some action can lead to consequences that are unwanted or undefined, such as loss of data or an equipment problem (ISO/IEC 26514:2008 Systems and software engineering--requirements for designers and developers of user documentation, 4.7) See Also: danger, warning, note


CBa. (1) conduct benchmarking activity (ISO/IEC 29155-2:2013 Systems and software engineering--Information technology project performance benchmarking framework--Part 2: Requirements for benchmarking, 4)


CBT. (1) computer-based training (ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.2)


CCB. (1) configuration control board (IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.2) (2) change control board (IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.2)


CCCS. (1) Client Conversion Code Sets (ISO/IEC 19500-2:2012 Information technology --Object Management Group--Common Object Request Broker Architecture (CORBA)--Part 2: Interoperability, 3.3)


CCM. (1) CORBA Component Model (ISO/IEC 19500-3:2012 Information technology--Object Management Group--Common Architecture Request Broker Architecture (CORBA)--Part 3: Components, 4.3)


CCMS. (1) component content management system (ISO/IEC/IEEE 26531:2015 Systems and software engineering -- Content management for product lifecycle, user and service management documentation, 5)


CCS. (1) Conversion Code Sets (ISO/IEC 19500-2:2012 Information technology --Object Management Group--Common Object Request Broker Architecture (CORBA)--Part 2: Interoperability, 3.3)


CD. (1) Compact Disk (ISO/IEC/IEEE 24765a:2011)


CD-ROM. (1) compact disc, read-only memory (IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.2) Syn: CD ROM


CDD. (1) capability development document (IEEE 15288.2:2014 IEEE Standard for Technical Reviews and Audits on Defense Programs, 3.2)


CDIF. (1) CASE Data Interchange Format (originally) (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 5.2)


CDIF clear text encoding. (1) clear text file encoding of a CDIF transfer file (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)


CDIF exporter. (1) tool that creates a CDIF transfer file (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)


CDIF family of standards. (1) set of standards that, when used together, provide a standard definition for the interchange of information between modeling tools (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)


CDIF graphical notation. (1) set of rules governing the representation of CDIF modeling concepts in diagrams (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)


CDIF identifier. (1) attribute that uniquely identifies an object in the model section of a transfer (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)


CDIF importer. (1) tool that reads a CDIF transfer file and uses it to create or modify a model (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)


CDIF meta-metamodel. (1) description of the set of concepts and notations used to define a metamodel (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2) Note: Specifically, the CDIF meta-metamodel defines an Entity-Relationship-Attribute model that is used to construct and define both metamodels and the CDIF meta-metamodel itself.


CDIF metaidentifier. (1) meta-meta-attribute that uniquely identifies a meta-object in the metamodel section of a transfer (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)


CDIF semantic metamodel. (1) description of the set of concepts and notations used to define a model (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2) Note: The CDIF semantic metamodel defines an Entity-Relationship-Attribute model that is used to construct and define models used in systems development.


CDIF transfer. (1) combination of a particular syntax, a particular encoding of that syntax, and a metamodel (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2) Note: In other words, a complete definition of the format and contents of a transfer.


CDIF transfer file. (1) transfer file conforming to ISO/IEC 15475 (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.1)


CDIF transfer format. (1) combination of a particular syntax and a particular encoding of that syntax which together provides a complete definition of the transfer format (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)


CDIF transfer syntax and encoding. (1) standard vehicle format supported by CDIF (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2) Note: The combination of SYNTAX.1 and ENCODING.1 forms the initial CDIF transfer syntax and encoding.


CDR. (1) critical design review (IEEE 15288.1:2014 IEEE Standard for Application of Systems Engineering on Defense Programs, 3.2) (2) common data representation (ISO/IEC 19500-2:2012 Information technology --Object Management Group--Common Object Request Broker Architecture (CORBA)--Part 2: Interoperability, 3.3)


CDRL. (1) contract data requirements list (ISO/IEC/IEEE 16326:2019 Systems and software engineering -- Life cycle processes -- Project management, 3)


CE. (1) Conformite' Europe'enne (ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.2)


central processing unit (CPU). (1) functional unit that consists of one or more processors and their internal storage (ISO/IEC 2382:2015 Information technology -- Vocabulary)


central tendency. (1) property of the central limit theorem predicting that the data observations in a distribution will tend to group around a central location (ISO/IEC/IEEE 24765h:2019) Note: The three typical measures of central tendency are the mean, median, and mode.


certificant. (1) recipient or holder of a certification (ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.4)


certificate. (1) document issued by a certification body, indicating that the named person has fulfilled the certification requirements (ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.5)


certification. (1) third-party attestation related to products, processes, systems, or persons (ISO/IEC 29110-2-1:2015 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 2-1: Framework and taxonomy, 4.15) (2) formal demonstration that a system or component complies with its specified requirements and is acceptable for operational use (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) process of confirming that a system or component complies with its specified requirements and is acceptable for operational use (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: written authorization that a computer system is secure and is permitted to operate in a defined environment Note: Certification is applicable to all objects of conformity assessment except for conformity assessment bodies themselves, to which accreditation is applicable. Certification of a management system is sometimes also called registration.


certification artifact. (1) tangible results from a certification process (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: inspection checklists, metrics, problem reports


certification body. (1) third-party conformity assessment body operating certification schemes (ISO/IEC 29110-2-1:2015 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 2-1: Framework and taxonomy, 4.16) Note: A certification body can be non-governmental or governmental (with or without regulatory authority).


certification criteria. (1) set of standards, rules, or properties to which an asset must conform in order to be certified to a certain level (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: null Note: Certification criteria are defined by a certification policy. Certification criteria can be specified as a set of certification properties that must be met.


certification process. (1) activities by which a certification body determines that a person fulfils certification requirements, including application, assessment, decision on certification, recertification and use of certificates and logos/marks (ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.6) (2) activities by which a certification body establishes that a person fulfills specified competence requirements, including application, evaluation, decision on certification, surveillance and recertification, and use of certificates and logos or marks (ISO/IEC TR 29154:2013 Software engineering--Guide for the application of ISO/IEC 24773:2008 (Certification of software engineering professionals--Comparison framework), 3.1) (3) process of assessing whether an asset conforms to predetermined certification criteria appropriate for that class of asset (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


certification property. (1) a statement about some feature or characteristic of an asset that can be assessed as being true or false during a certification process (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: null Note: Properties can relate to what an asset is, what it does, or how it relates to its operating environment. An assessment of a certification quality factor is accomplished by assessing the underlying certification properties.


certification requirements. (1) set of specified requirements, including requirements of the scheme to be fulfilled in order to establish or maintain certification of a candidate (ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.7)


certification scheme. (1) competence and other requirements related to specific occupational or skilled categories of persons (ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.8) (2) certification system related to specified products, to which the same specified requirements, specific rules, and procedures apply (ISO/IEC 29110-2-1:2015 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 2-1: Framework and taxonomy, 4.17) (3) specific certification requirements related to specified categories of persons, to which the same particular standards and rules and the same procedures apply (ISO/IEC TR 29154:2013 Software engineering--Guide for the application of ISO/IEC 24773:2008 (Certification of software engineering professionals--Comparison framework), 3.2) Note: [ISO/IEC 17024] A certification scheme addresses a candidate's knowledge, skill, competence or proficiency, but it also includes requirements for certified person's ongoing maintenance of proficiency. A specific scheme also contains declarations concerning scope and title; the criteria for assessment of the certified person; and declarations regarding validation of the scheme. The scheme is documented.


certification scheme owner. (1) person or organization that is responsible for developing and maintaining a specific certification scheme (ISO/IEC 29110-2-1:2015 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 2-1: Framework and taxonomy, 4.18) Note: The certification scheme owner can be the certification body itself, a governmental authority, trade association, group of certification bodies, or other.


CFD. (1) cumulative flow diagram (Software Extension to the PMBOK(R) Guide Fifth Edition)


CFP. (1) COSMIC function point (ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 3) (2) call for proposals (ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 3.2)


chain. (1) one or more tasks submitted to the SUT in a defined sequence (ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.3) (2) sequence of actions within an activity where, for each adjacent pair of actions, occurrence of the first action is necessary for the occurrence of the second action (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.1.1)


chain type. (1) classification of chains which is defined by the sequence of tasks types (ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.4) Note: The emulated users submit only chains of specified chain types to the SUT.


change. (1) the modification of an existing application comprising additions, changes and deletions (ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10) (2) add, move, modify, removal of a configuration item (CI) (ISO/IEC TR 29110-5-3:2018 Systems and software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 5-3: Service delivery guidelines, 3.4) See Also: enhancement


change control. (1) a process whereby modifications to documents, deliverables, or baselines associated with the project are identified, documented, approved, or rejected (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) See Also: configuration control, version control


change control board (CCB). (1) a formally chartered group responsible for reviewing, evaluating, approving, delaying, or rejecting changes to a project, and for recording and communicating such decisions (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) Syn: change authority See Also: configuration control board


change control procedure. (1) actions taken to identify, document, review, and authorize changes to a software or documentation product that is being developed (ISO/IEC 26514:2008 Systems and software engineering--requirements for designers and developers of user documentation, 4.8) 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 control system. (1) a set of procedures that describes how modifications to the project deliverables and documentation are managed and controlled (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


change control tools. (1) Manual or automated tools to assist with change and/or configuration management. At a minimum, the tools should support the activities of the change control board (CCB). (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


change dump. (1) selective dump of those storage locations whose contents have changed since some specified time or event (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: differential dump See Also: dynamic dump, memory dump, postmortem dump, selective dump, snapshot dump, static dump


change log. (1) a comprehensive list of changes submitted during the project and their current status (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


change management. (1) judicious use of means to effect a change, or a proposed change, to a product or service (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: configuration management


change management plan. (1) A component of the project management plan that establishes the change control board, documents the extent of its authority, and describes how the change control system will be implemented. (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


change package. (1) collection of objects that have been changed and approved and will be transferred to the production environment (ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.10)


change project function point count. (1) a count that measures the work-output arising from modifications to an existing application that add, change or delete user functions delivered when the project is complete (ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)


change record. (1) record containing details of which configuration items are affected and how they are affected by an authorized change (ISO/IEC/IEEE 24765a:2011)


change request. (1) a formal proposal to modify any document, deliverable, or baseline (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) (2) formal procedure for submitting a request for an adjustment of a configuration item (ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.5) See Also: modification request, request for change


change set. (1) collection of objects which can undergo change as the result of a release (ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.11)


changeover system. (1) temporary information processing system used to facilitate the transition from an operational system to its successor (ISO/IEC 2382:2015 Information technology -- Vocabulary)


channel. (1) approach to distributing products and services from the original supplier to the end-user organization (ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.3) (2) configuration of stubs, binders, protocol objects and interceptors providing a binding between a set of interfaces to basic engineering objects, through which interaction can occur (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.8) Note: Typical channels for software include direct, VAR, OEM, reseller, and educational reseller. Bindings that require channels are referred to as distributed bindings in the engineering language; bindings between engineering objects that do not require channels (e.g. between engineering objects in the same cluster) are referred to as local bindings. Syn: distribution channel


channel capacity. (1) maximum amount of information that can be transferred on a given channel per unit of time; usually measured in bits per second or in baud. (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: memory capacity, storage capacity


channel partner. (1) person or entity working with a software licensor or another person/entity within the channel who facilitates the sale of software to the end-user (ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.4) Example: original equipment manufacturer (OEM), reseller, vendor


character. (1) letter, digit, or other symbol that is used to represent information (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) member of a set of elements that is used for the representation, organization, or control of data (ISO/IEC 2382:2015 Information technology -- Vocabulary)


character set. (1) collection of characters used in an encoding to represent terminal symbols (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2) Note: The character set used is significant in the encoding of text and string meta-attributes for a CDIF transfer.


character type. (1) data type whose members can assume the values of specified characters and can be operated on by character operators, such as concatenation (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: enumeration type, integer type, logical type, real type


characteristic entity. (1) meta-entity that provides additional attribution for another meta-object (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2) Note: Other common names for characteristic entity are attributive entity and dependent entity. Each instance of a characteristic meta-entity is logically only related to one instance of one other meta-object, therefore an importer could incorporate the meta-attributes of a characteristic meta-entity with those of the 'owning' meta-object, where the owning meta-object is the one to which the characteristic meta-entity is related with a cardinality of 1:1.


characteristic of FUR. (1) a distinctive property of the FUR that is important for identifying the functional domain to which a specific set of FUR belongs (ISO/IEC TR 14143-5:2004 Information technology -- Software measurement -- Functional size measurement -- Part 5: Determination of functional domains for use with functional size measurement, 3.1)


chart of accounts. (1) numbering system used by a project or organization to identify costs by category, such as labor, supplies, materials, and equipment (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: code of accounts


checklist analysis. (1) a technique for systematically reviewing materials using a list for accuracy and completeness (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


checklist-based reviewing. (1) review technique guided by a list of questions or required attributes (ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.4)


checkout. (1) testing conducted in the operational or support environment to ensure that a software product performs as required after installation (ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)


checkpoint. (1) point in a computer program at which program state, status, or results are checked or recorded (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) object template derived from the state and structure of an engineering object that can be used to instantiate another engineering object, consistent with the state of the original object at the time of checkpointing (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.20)


checkpointing. (1) creating a checkpoint (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.21) Note: Checkpoints can only be created when the engineering object involved satisfies a pre-condition stated in a checkpointing policy.


checksheets. (1) a tally sheet that can be used as a checklist when gathering data (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) Syn: checksheet, check sheet


chief programmer. (1) leader of a chief programmer team; a senior-level programmer whose responsibilities include producing key portions of the software assigned to the team, coordinating the activities of the team, reviewing the work of the other team members, and having an overall technical understanding of the software being developed (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: backup programmer, chief programmer team


chief programmer team. (1) software development group that consists of a chief programmer, a backup programmer, a secretary/librarian, and additional programmers and specialists as needed, and that employs procedures designed to enhance group communication and to make optimum use of each member's skills (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: backup programmer, chief programmer, egoless programming


child box. (1) box in a child diagram (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.27)


child diagram. (1) decomposition diagram related to a specific box by exactly one child/parent relationship (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.28)


child entity. (1) entity in a specific relationship whose instances can be related to zero or one instance of the other entity (parent entity) (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.22) Note: [key style]


CI. (1) configuration item (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


CIDL. (1) Component Implementation Definition Language (ISO/IEC 19500-3:2012 Information technology--Object Management Group--Common Architecture Request Broker Architecture (CORBA)--Part 3: Components, 4.3)


CIF. (1) Component Implementation Framework (ISO/IEC 19500-3:2012 Information technology--Object Management Group--Common Architecture Request Broker Architecture (CORBA)--Part 3: Components, 4.3)


CIM. (1) Computer Integrated Manufacturing (ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)


clabject. (1) dual entity that is a class and an object at the same time (ISO/IEC 24744:2014 Software Engineering--Metamodel for development methodologies, 3.13) Note: Because of their dual nature, clabjects exhibit a class facet and an object facet, and can work as either at any time. Instances of powertypes are usually viewed as clabjects, since they are objects (because they are instances of a type, the powertype) and also classes (subtypes of the partitioned type).


claim. (1) a request, demand, or assertion of rights by a seller against a buyer, or vice versa, for consideration, compensation, or payment under the terms of a legally binding contract, such as for a disputed change. (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) (2) true-false statement about the limitations on the values of an unambiguously defined property--called the claim's property--and limitations on the uncertainty of the property's values falling within these limitations during the claim's duration of applicability under stated conditions (ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.1.2) (3) proposition representing a requirement of the system-of-interest that enables the system-of-interest to achieve tolerable risk if it were met (ISO/IEC 15026-3:2015 Systems and software engineering -- Systems and software assurance -- Part 3: System integrity levels, 3.2) Note: Claims usually relate to specified versions of a product. The statement of a claim does not mean that the only possible intent or desire is to show it is true. Sometimes claims are made for the purpose of evaluating whether they are true or false or undertaking an effort to establish what is true. In its entirety, a claim is an unambiguous declaration of an assertion with any associated conditionality, giving explicit details including limitations on values and uncertainty. It could be about the future, present, or past. A safety goal is an instance of a claim.


claims administration. (1) the process of processing, adjudicating, and communicating contract claims (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


class. (1) abstraction of the knowledge and behavior of a set of similar things (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.23) (2) static programming entity in an object-oriented program that contains a combination of functionality and data (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) of <X>s, the set of all <X>s satisfying a type (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.10) Note: Classes are used to represent the notion of "things whose knowledge or actions are relevant." See Also: type


class hierarchy. (1) ordering of classes, in which a subclass is a specialization of its superclass (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: A class inherits attributes and relationships from its superclass and can define additional attributes and relationships of its own.


class-level attribute. (1) mapping from the class itself to the instances of a value class (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.24)


class-level operation. (1) mapping from the (cross product of the) class itself and the instances of the input argument types to the (cross product of the) instances of the other (output) argument types (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.25)


class-level responsibility. (1) responsibility that represents some aspect of the knowledge, behavior, or rules of the class as a whole (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.26) Example: The total registeredVoterCount would be a class-level property of the class registeredVoter; there would be only one value of registeredVoterCount for the class as a whole. See Also: instance-level responsibility


classification. (1) manner in which the assets are organized for ease of search and extraction within a reuse library (IEEE 1517-2010 IEEE Standard for Information Technology--System and software life cycle processes--Reuse processes, 3)


classification axis. (1) total range of a mapping of systems and software for categorizing them from a particular perspective (ISO/IEC TR 12182:2015 Systems and software engineering--Framework for categorization of IT systems and software, and guide for applying it, 3.7)


clear. (1) to set a variable, register, or other storage location to zero, blank, or other null value (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: initialize, reset


clear text file encoding. (1) class of techniques for representing data based on first defining a human readable representation using some specific character repertoire and then defining an encoding for that repertoire (ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.1)


client. (1) code or process that invokes an operation on an object (ISO/IEC 19500-2:2012 Information technology --Object Management Group--Common Object Request Broker Architecture (CORBA)--Part 2: Interoperability, 3.2.3) (2) of a service, any entity capable of requesting the service (ISO/IEC 19500-1:2012 Information technology-- Object Management Group--Common Object Request Broker Architecture (CORBA)--Part 1: Interfaces, 5.3) (3) for certification, the organization that is responsible to a certification body for ensuring certification requirements, including product requirements, are fulfilled (ISO/IEC 29110-2-1:2015 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 2-1: Framework and taxonomy, 4.19)


client object. (1) object which requests that a service be performed by another object (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.4.5)


client-side. (1) node, cluster or capsule, which: a) contains a basic engineering object corresponding to a computational client object; and b) contains, or is potentially capable of containing, stub, binder and protocol objects in a channel supporting operations involving the client object (ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 3.3.5)


clock pulse generator (CPG). (1) electronic unit to produce uniform timed signals (ISO/IEC/IEEE 24765d:2015) Example: embedded in an MCU


cloning. (1) instantiating a cluster from a cluster checkpoint (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.24)


Close Procurements. (1) the process of completing each project procurement (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


Close Project or Phase. (1) the process of finalizing all activities for the project, phase, or contract (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


closed loop. (1) loop that has no exit and whose execution can be interrupted only by intervention from outside the computer program or procedure in which the loop is located (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: UNTIL, WHILE


closed subroutine. (1) subroutine that is stored at one given location rather than being copied into a computer program at each place that it is called (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: open subroutine


closed term. (1) term comprising constants and operators but no variables (ISO/IEC/IEEE 24765i:2020) Syn: ground term


cluster. (1) configuration of basic engineering objects forming a single unit for the purposes of deactivation, checkpointing, reactivation, recovery and migration (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.2) Example: a segment of virtual memory containing objects


cluster checkpoint. (1) cluster template containing checkpoints of the basic engineering objects in a cluster (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.22)


cluster manager. (1) engineering object which manages the basic engineering objects in a cluster (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.3)


cluster template. (1) object template for a configuration of objects and any activity required to instantiate those objects and establish initial bindings (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.19)


CM. (1) configuration management (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) control manager (ISO/IEC TR 29110-5-3:2018 Systems and software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 5-3: Service delivery guidelines, 3.6)


CM service. (1) abstract description of work done by CM tools (ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.8) Syn: configuration management service


CM tool. (1) software product that can assist software engineers by providing automated support for configuration management activities (ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.9) Syn: configuration management tool


CMDB. (1) configuration management database (IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.2)


CMIP. (1) Common Management Information Protocol (ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)


CMIR. (1) client makes it right (ISO/IEC 19500-2:2012 Information technology --Object Management Group--Common Object Request Broker Architecture (CORBA)--Part 2: Interoperability, 3.3)


CMIS. (1) Common Management Information Service (ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)


CMP. (1) configuration management plan (IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.2)


CMT. (1) container-managed transaction (ISO/IEC 19500-3:2012 Information technology--Object Management Group--Common Architecture Request Broker Architecture (CORBA)--Part 3: Components, 4.3)


CNCS. (1) Client Native Code Set (ISO/IEC 19500-2:2012 Information technology --Object Management Group--Common Object Request Broker Architecture (CORBA)--Part 2: Interoperability, 3.3)


CO. (1) service control process (ISO/IEC TR 29110-5-3:2018 Systems and software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 5-3: Service delivery guidelines, 4.1)


co-existence. (1) degree to which a product can perform its required functions efficiently while sharing a common environment and resources with other products, without detrimental impact on any other product (ISO/IEC 25010:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--System and software quality models, 4.2.3.1) Syn: coexistence


code. (1) in software engineering, computer instructions and data definitions expressed in a programming language or in a form output by an assembler, compiler, or other translator (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) to express a computer program in a programming language (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) character or bit pattern that is assigned a particular meaning (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: a status code See Also: source code, object code, machine code, micro code


code breakpoint. (1) breakpoint that is initiated upon execution of a given computer instruction (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: control breakpoint See Also: data breakpoint, dynamic breakpoint, epilog breakpoint, programmable breakpoint, prolog breakpoint, static breakpoint


code data. (1) type of data entities used for software sizing (in addition to business data and reference data) (IEEE 2430-2019 Trial-Use Standard for Software Non-Functional Sizing Measurements, 3.1) Note: Code data usually exists to satisfy non-functional requirements (NFR) from the user (for quality requirements, physical implementation or a technical reason). Code data provides a list of valid values that a descriptive attribute may have. Typically, the attributes of the code data are Code, Description or other standard attributes describing the code; e.g., standard abbreviation, effective date, termination date, audit trail data.


code freeze. (1) period during which non-critical changes to the code are not allowed (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


code generator. (1) software tool that accepts as input the requirements or design for a computer program and produces source code that implements the requirements or design generator (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: application


code of accounts. (1) a numbering system used to uniquely identify each component of the work breakdown structure (WBS) (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) See Also: chart of accounts


code of ethics standard. (1) standard that describes the characteristics of a set of moral principles dealing with accepted standards of conduct by, within, and among professionals (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


code review. (1) meeting at which software code is presented to project personnel, managers, users, customers, or other interested parties for comment or approval (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: design review, formal qualification review, requirements review, test readiness review


code tuning. (1) process of making statement-level changes to a program to make it more efficient (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) making changes to program source code to optimize performance, usually to increase speed or reduce memory usage (3) changes made to program source code for the purpose of optimizing performance, usually to increase speed or reduce memory usage (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


coding. (1) in software engineering, the process of expressing a computer program in a programming language (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) transforming of logic and data from design specifications (design descriptions) into a programming language (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


coerce. (1) to treat an object of one type as an object of another type by using a different object (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.28) See Also: cast


cohesion. (1) manner and degree to which the tasks performed by a single software module are related to one another (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) in software design, a measure of the strength of association of the elements within a module (ISO/IEC TR 19759:2016 Software Engineering -- Guide to the Software Engineering Body of Knowledge (SWEBOK)) Note: Types include coincidental, communicational, functional, logical, procedural, sequential, and temporal. Syn: module strength See Also: coupling


coincidental cohesion. (1) type of cohesion in which the tasks performed by a software module have no functional relationship to one another (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: communicational cohesion, functional cohesion, logical cohesion, procedural cohesion, sequential cohesion, temporal cohesion


collaboration. (1) cooperative exchange of requests among classes and instances in order to achieve some goal (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.29)


collaborative system of systems. (1) system of systems (SoS) in which component systems interact more or less voluntarily to fulfill agreed-upon central purposes (ISO/IEC/IEEE 21841:2019 Systems and software engineering--Taxonomy of systems of systems, 3.2.2) Note: Constituent systems collectively decide how to provide or deny service, thereby providing means of enforcing and maintaining consistency. Syn: collaborative SoS


collapse. (1) to terminate development on one branch by integrating it with another (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


Collect Requirements. (1) the process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


collection cardinality. (1) specification, for a collection-valued property, of how many members the value of the property, that is, the collection, can or is required to have for each instance (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.30) See Also: cardinality constraint


collection class. (1) class in which each instance is a group of instances of other classes (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.31)


collection-valued. (1) value that is complex (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.33) Note: That is, having constituent parts. See Also: scalar


collection-valued class. (1) class in which each instance is a collection of values (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.34) See Also: scalar-valued class


collection-valued property. (1) property that maps to a collection class (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.35) Syn: collection property See Also: scalar-valued property


colocation. (1) an organizational placement strategy where the project team members are physically located close to one another in order to improve communication, working relationships, and productivity (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) Syn: co-location


comfort. (1) degree to which the user is satisfied with physical comfort (ISO/IEC 25010:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--System and software quality models, 4.1.3.4)


command. (1) expression that can be input to a computer system to initiate an action or affect the execution of a computer program (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: the 'logon' command to initiate a computer session


command language. (1) language used to express commands to a computer system (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: command-driven


command-driven. (1) pertaining to a system or mode of operation in which the user directs the system through commands (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: command driven See Also: menu-driven


comment. (1) information embedded within a computer program, job control statements, or a set of data that provides clarification to human readers but does not affect machine interpretation (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


commercial-off-the-shelf (COTS). (1) [software] product available for purchase and use without the need to conduct development activities (ISO/IEC/IEEE 90003:2018 Software engineering -- Guidelines for the application of ISO 9001:2015 to computer software, 3.4) Note: COTS software product includes the product description (including all cover information, data sheet, web site information, etc.), the user documentation (necessary to install and use the software), the software contained on a computer sensible media (disk, CD-ROM, internet downloadable, etc.). Software is mainly composed of programs and data. This definition applies also to product descriptions, user documentation and software which are produced and supported as separate manufactured goods, but for which typical commercial fees and licensing considerations do not apply. Syn: commercial off the shelf, Commercial-Off-The-Shelf See Also: software product


commercial-off-the-shelf software product. (1) software product defined by a market-driven need, commercially available, and whose fitness for use has been demonstrated by a broad spectrum of commercial users (ISO/IEC 25040:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Evaluation process, 4.6) Syn: COTS software product


commissioning. (1) procedures prior, or related, to the handing over of a product ready to be placed into service (IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.2) Note: Commissioning may include final acceptance testing, the handing over of relevant documentation for the supported product, or instructing personnel.


commit. (1) 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 (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


commit message. (1) explanatory message accompanying a commit (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: often contains a brief description of the change and its rationale; names of contributors, reviewers, or approvers; a reference to third-party software from which the change was obtained; a schedule for integrating it to other branches; and a reference to the issue identifier associated with the change


commit privileges. (1) person's authority to commit changes (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: Sometimes privileges are associated with a specific part of the product (for example, artwork or documentation) or a specific branch.


commit war. (1) series of conflicting and mutually reversing commits introduced by developers who disagree on how a particular element is being coded (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: sometimes starts with a hostile backout.


commit window. (1) period during which commits are allowed for a specific branch (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: In some development environments, commit windows for a maintenance branch might only open for short periods a few times a year.


commitment. (1) action resulting in an obligation by one or more of the participants in the act to comply with a rule or perform a contract (ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.6.2) Note: The enterprise object(s) participating in an action of commitment can be parties or agents acting on behalf of a party or parties. In the case of an action of commitment by an agent, the principal becomes obligated.


committer. (1) developer with commit privileges (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


common ancestor constraint. (1) constraint that involves two or more relationship paths to the same ancestor class and states either that a descendent instance must be related to the same ancestor instance through each path or that it must be related to a different ancestor instance through each path (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.36)


common cause. (1) source of variation of a process that exists because of normal and expected interactions among components of a process (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: On a control chart, it appears as part of the random process variation (i.e., variation from a process that would be considered normal or not unusual), and is indicated by a random pattern of points within the control limits. Syn: random cause See Also: special cause


common storage. (1) portion of main storage that can be accessed by two or more modules in a software system (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: common area, common block See Also: global data


common-environment coupling. (1) type of coupling in which two software modules access a common data area (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: common coupling, common environment coupling See Also: content coupling, control coupling, data coupling, hybrid coupling, pathological coupling


commonality. (1) set of functional and non-functional characteristics that is shared by all applications belonging to the product line (ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.9)


communication constraints. (1) restrictions on the content, timing, audience, or individual who will deliver a communication, usually stemming from specific legislation or regulation, technology, or organizational policies (ISO/IEC/IEEE 24765h:2019)


communication interface. (1) interface of a protocol object that can be bound to an interface of either an interceptor object or another protocol object at an interworking reference point (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.14)


communication management. (1) management of objects which support the communication between objects within an ODP system (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 14.2)


communication management plan. (1) a component of the project, program, or portfolio management plan that describes how, when, and by whom information about the project will be administered and disseminated (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) Syn: communications management plan


communication methods. (1) a systematic procedure, technique, or process used to transfer information among project stakeholders (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


communication models. (1) a description, analogy or schematic used to represent how the communication process will be performed for the project (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition) Syn: communication model


communication requirements analysis. (1) an analytical technique to determine the information needs of the project stakeholders through interviews, workshops, study of lessons learned from previous projects, etc. (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


communication styles assessment. (1) a technique to identify the preferred communication method, format, and content for stakeholders for planned communication activities (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


communication technology (CT). (1) specific tools, systems, computer programs, etc., used to transfer information among project stakeholders (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Sixth Edition)


communicational cohesion. (1) type of cohesion in which the tasks performed by a software module use the same input data or contribute to producing the same output data (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: coincidental cohesion, functional cohesion, logical cohesion, procedural cohesion, sequential cohesion, temporal cohesion


communications domain. (1) set of protocol objects capable of interworking (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.13)


communications planning. (1) process of defining how to meet the information and communication needs of the stakeholders: who needs what information, when they need it, and how it will be given to them (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


community. (1) configuration of objects formed to meet an objective (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 5.1.1) Note: The objective is expressed as a contract which specifies how the objective can be met.


community object. (1) composite enterprise object that represents a community (ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.2.2) Note: Components of a community object are objects of the community represented


compact disc read only memory (CD-ROM). (1) optical disk which can be read, but not erased or rewritten (ISO/IEC/IEEE 24765c:2014)


compaction. (1) in microprogramming, the process of converting a microprogram into a functionally equivalent microprogram that is faster or shorter than the original (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: local compaction, global compaction


comparator. (1) software tool that compares two computer programs, files, or sets of data to identify commonalities or differences (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: Typical objects of comparison are similar versions of source code, object code, database files, or test results.


compatibility. (1) degree to which a product, system or component can exchange information with other products, systems or components, or perform its required functions, while sharing the same hardware or software environment (ISO/IEC 25010:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--System and software quality models, 4.2.3) (2) ability of two or more systems or components to exchange information (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) capability of a functional unit to meet the requirements of a specified interface without appreciable modification (ISO/IEC 2382:2015 Information technology -- Vocabulary)


compatibility testing. (1) type of testing that measures the degree to which a test item can function satisfactorily alongside other independent products in a shared environment (co-existence), and where necessary, exchanges information with other systems or components (interoperability) (ISO/IEC/IEEE 29119-1:2013 Software and systems engineering--Software testing--Part 1: Concepts and definitions, 4.6)


compensatory decision technique. (1) multiple-attribute decision technique that allows better performance in some of the attributes to compensate for lower performance in one or more of the other attributes; use of trade-offs (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: noncompensatory decision technique, additive weighting, analytic hierarchy process, nondimensional scaling


compensatory model. (1) multiple-criteria decision-making model, in which a composite measure is composed of individually weighted terms and where criteria (also referred to as attribute terms) with a high value can compensate for those of a low value in proportion to each weight (ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.2) Note: A compensatory model suggests that improving the more important measures (those with a higher weighting) is more likely to increase or improve the overall composite value than improving the less important ones. This model assumes that the weight (influence level) of criteria remains the same regardless of the measured level of the criteria.


competence. (1) ability to apply knowledge and skills to achieve intended results (ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.11) (ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.9) (2) demonstrated ability to apply knowledge and skills, and relevant personal attributes, as defined in the certification scheme (ISO/IEC TR 29154:2013 Software engineering--Guide for the application of ISO/IEC 24773:2008 (Certification of software engineering professionals--Comparison framework), 3.3) Note: Results are defined with respect to tasks, functions or responsibilities, which in turn are job/role/title-related. Competence can be used to refer to general ability (e.g. overall competence), while competency can be used to refer to a specific ability (e.g. competency in design of user interfaces). Syn: competency See Also: competent


competent. (1) having the combination of knowledge, formal and informal skills, training, experience, and behavioral attributes required to perform a task or role (ISO/IEC/IEEE 24765c:2014) See Also: competence


competent assessor. (1) assessor who has demonstrated the competencies to conduct an assessment and to monitor and verify the conformance of a process assessment (ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.12) (ISO/IEC 29110-2-1:2015 Software engineering--Lifecycle profiles for Very Small Entities (VSEs)--Part 2-1: Framework and taxonomy, 4.19) Syn: lead assessor


competent person. (1) person who has acquired through training, qualifications or experience, or a combination of these, the knowledge and skills enabling that person to perform a specified task (IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.3) See Also: skilled person


compile. (1) to translate a computer program expressed in a high-order language into its machine language equivalent (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: assemble, decompile, interpret


compile-and-go. (1) operating technique in which there are no stops between the compiling, linking, loading, and execution of a computer program (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


compiler. (1) computer program that translates programs expressed in a high-order language into their machine language equivalents (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: assembler, interpreter, cross-compiler, incremental compiler, root compiler


compiler code. (1) computer instructions and data definitions expressed in a form that can be recognized and processed by a compiler (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: assembly code, interpretive code, machine code


compiler directive source statement. (1) source statement that defines macros, or labels, or directs the compiler to insert external source statements (for example, an include statement), or directs conditional compilation, or is not described by one of the other type attributes (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


compiler generator. (1) translator or interpreter used to construct part or all of a compiler (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: compiler compiler, metacompiler


complaint. (1) record of perceived non-compliance with a service level agreement or customer dissatisfaction with service (ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.2)


complete. (1) <documentation> including all critical information and any necessary, relevant information for the intended audience (ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.2)


complete ICOM code. (1) diagram feature reference in which dot notation joins an ICOM code to a diagram reference (IEEE 1320.1-1998 (R2004) IEEE Standard for Functional Modeling Language - Syntax and Semantics for IDEF0, 2.1.29)


complete procedure. (1) all those activities which commence with entry to the procedure and conclude with exit from the procedure (ISO/IEC/IEEE 24765a:2011)


complete table. (1) decision table where for all combinations of condition entries there exists a satisfying rule (ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.17) Example: null Note: In practical terms extended entry tables include limited entries and are therefore mixed entry tables. Any extended or mixed entry table can be transformed into a limited entry table


completeness. (1) degree to which an IT service supports all the goals, objectives, and data specified by the user (ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.1.1)


completion code. (1) code communicated to a job stream processor by a batch program to influence the execution of succeeding steps in the input stream (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


completion criteria. (1) conditions under which the testing activities are considered complete (ISO/IEC/IEEE 29119-2:2013 Software and systems engineering--Software testing--Part 2: Test processes, 4.2)


completion time theorem. (1) real-time scheduling theorem (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: For a set of independent periodic tasks, if each task meets its first deadline when all tasks start at the same time, the deadlines will be met for any combination of start times.


complex programmable logic device (CPLD). (1) hardware component with a fully programmable AND/OR gate array (ISO/IEC/IEEE 24765d:2015)


complexity. (1) degree to which a system's design or code is difficult to understand because of numerous components or relationships among components (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) pertaining to any of a set of structure-based metrics that measure the attribute in (1) (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (3) degree to which a system or component has a design or implementation that is difficult to understand and verify (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: simplicity


complexity matrix. (1) a table used to allocate a weight to a function type (ISO/IEC 24570:2005 Software engineering -- NESMA functional size measurement method version 2.1 -- Definitions and counting guidelines for the application of Function Point Analysis) Note: The matrix allocates this weight on the basis of the number of data element types in combination with the number of record types or file types referenced.


complexity of a function. (1) the weight allocated to a function on the basis of which a number of function points is assigned to the function (ISO/IEC 24570:2005 Software engineering -- NESMA functional size measurement method version 2.1 -- Definitions and counting guidelines for the application of Function Point Analysis)


compliance. (1) doing what has been asked or ordered, as required by rule or law (IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2) Example: comply with a regulation See Also: conformance


component. (1) entity with discrete structure, such as an assembly or software module, within a system considered at a particular level of analysis (ISO/IEC 25010:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--System and software quality models, 4.3.3) (2) one part that makes up a system (IEEE 1012-2016 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1) (3) object that encapsulates its own template, so that the template can be interrogated by interaction with the component (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.26) (4) specific, named collection of features that can be described by an IDL component definition or a corresponding structure in an interface repository (ISO/IEC 19500-3:2012 Information technology--Object Management Group--Common Architecture Request Broker Architecture (CORBA)--Part 3: Components, 4.1) (5) functionally or logically distinct part of a system (ISO/IEC 19506:2012 Information technology -- Object Management Group Architecture-Driven Modernization (ADM) -- Knowledge Discovery Meta-Model (KDM), 4) (6) object with a discrete information type that is stored in a component content management system, such as a topic, prerequisite, section, image, or video (ISO/IEC/IEEE 26531:2015 Systems and software engineering -- Content management for product lifecycle, user and service management documentation, 4.3) (7) product used as a constituent in an assembled product, system or plant (IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.4) Note: A component can be hardware or software and can be subdivided into other components. Component refers to a part of a whole, such as a component of a software product or a component of a software identification tag. The terms module, component, and unit are often used interchangeably or defined to be subelements of one another in different ways depending upon the context. The relationship of these terms is not standardized. A component can be independently managed or not from the end-user or administrator's point of view. See Also: element, unit


component content management system (CCMS). (1) content management system that supports the entire document- or information-development life cycle from authoring through review and publishing, including the reuse of modular content (ISO/IEC/IEEE 26531:2015 Systems and software engineering -- Content management for product lifecycle, user and service management documentation, 4.4) Note: In case the modular content is XML-based, the individual XML elements available for management are defined by the XML schema or DTD. It is not necessary to specify numerous markup languages.


component dependencies. (1) all the components that are linked to, directly or indirectly, from a single parent component (ISO/IEC/IEEE 26531:2015 Systems and software engineering -- Content management for product lifecycle, user and service management documentation, 4.5) Example: The relationship of a source hazard statement to its insertion in a topic at time of publication


component home. (1) meta-type that acts as a manager for instances of a specified component type (ISO/IEC 19500-3:2012 Information technology--Object Management Group--Common Architecture Request Broker Architecture (CORBA)--Part 3: Components, 4.1) Note: Component home interfaces provide operations to manage component life cycles, and optionally, to manage associations between component instances and primary key values.


component implementation. (1) activity of realizing a component, including unit test (ISO/IEC 26553:2018 Information technology-Software and systems engineering- Tools and methods for product line realization, 3.8)


component integration test. (1) testing of groups of related components (ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)


component standard. (1) standard that describes the characteristics of data or program components subdivided into other components (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


component testing. (1) testing of individual hardware or software components (IEEE 1012-2016 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)


component-aware client. (1) client that is defined using the IDL extensions in the component model (ISO/IEC 19500-3:2012 Information technology--Object Management Group--Common Architecture Request Broker Architecture (CORBA)--Part 3: Components, 4.1)


composite key. (1) key comprising of two or more attributes (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.38) Note: [key style]


composite measure. (1) variable derived from a set of operations of a construct's multi-item measures defined according to a construct specification (either reflective or formative) that is the way in which the latent variable representing the construct of interest is linked to its measures (ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.4)


composite object. (1) object expressed as a composition (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.2)


composite task. (1) task containing nested objects (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


composite type. (1) data type each of whose members is composed of multiple data items (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: a data type called PAIRS whose members are ordered pairs (x,y) See Also: atomic type


composition. (1) combination of two or more objects yielding a new object, at a different level of abstraction (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.1.a) (2) combination of two or more behaviors yielding a new behavior (ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.1.b) (3) both the set of artifacts that constitute the unit of component implementation, and the definition of this aggregate entity (ISO/IEC 19500-3:2012 Information technology--Object Management Group--Common Architecture Request Broker Architecture (CORBA)--Part 3: Components, 4.1) See Also: decomposition


computation data use. (1) use of the value of a variable in any type of statement (ISO/IEC/IEEE 29119-4:2015 Software and systems engineering -- Software testing -- Part 4: Test techniques, 4.4) Syn: c-use


computational component. (1) component specified in a computational viewpoint that has a control interface and declared sets of (a) operation interfaces in which it plays a server role (facets), (b) operation interfaces in which it plays a client role (receptacles), (c) operation interfaces originating announcements carrying notifications of typed events (event sources), (d) operation interfaces consuming announcements carrying notifications of typed events (event sinks), (e) operation interfaces supporting accessors and mutators for attributes (attributes) (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.16)


computational container. (1) container for a declared set of computational component types that has a management interface at which it can be requested to create a computational component of one of the types and add it to the container's content, delete a computational component from the container, list the computational components it currently contains, and list the computational factories it provides (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.17)


computational factory. (1) factory that returns an interface reference to the computational object it creates (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.15)


computational interface template. (1) interface template for either a signal interface, a stream interface, or an operation interface (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.10) Note: A computational interface template comprises a signal, a stream or an operation interface signature as appropriate, a behavior specification and an environment contract specification.


computational object template. (1) object template which comprises a set of computational interface templates which the object template can instantiate, a behavior specification, and an environment contract specification (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.9)


computational viewpoint. (1) viewpoint on an ODP system and its environment which enables distribution through functional decomposition of the system into objects which interact at interfaces (ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.1.1.3)


computer. (1) functional unit that can perform substantial computations, including numerous arithmetic operations and logic operations without human intervention (ISO/IEC 2382:2015 Information technology -- Vocabulary) Note: A computer can consist of a stand-alone unit or several interconnected units. See Also: computing device


computer center. (1) facility that includes personnel, hardware, and software, organized to provide information processing services (ISO/IEC 2382:2015 Information technology -- Vocabulary) Syn: data processing center


computer crime. (1) crime committed through the use, modification, or destruction of hardware, software, or data (ISO/IEC 2382:2015 Information technology -- Vocabulary)


computer generation. (1) category in a historical classification of computers based mainly on the technology used in their manufacture (ISO/IEC 2382:2015 Information technology -- Vocabulary) Example: first generation based on relays or vacuum tubes, the second on transistors, the third on integrated circuits


computer graphics. (1) methods and techniques for construction, manipulation, storage, and display of images by means of a computer (ISO/IEC 2382:2015 Information technology -- Vocabulary)


computer instruction. (1) statement in a programming language, specifying an operation to be performed by a computer and the addresses or values of the associated operands (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) loosely, any executable statement in a computer program (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: Move A to B See Also: instruction format, instruction set


computer language. (1) language designed to enable humans to communicate with computers (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: design language, query language, programming language


computer network. (1) data processing nodes and their interconnections for the purpose of data communication (ISO/IEC 2382:2015 Information technology -- Vocabulary)


computer performance evaluation. (1) engineering discipline that measures the performance of computer systems and investigates methods by which that performance can be improved (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: system profile, throughput, utilization, workload model


computer program. (1) combination of computer instructions and data definitions that enable computer hardware to perform computational or control functions (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) syntactic unit that conforms to the rules of a particular programming language and that is composed of declarations and statements or instructions needed for a certain function, task, or problem solution (ISO/IEC 2382:2015 Information technology -- Vocabulary) See Also: software


computer program abstract. (1) brief description of a computer program that provides sufficient information for potential users to determine the appropriateness of the program to their needs and resources (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


computer resource. (1) element of a data processing system needed to perform required operations (ISO/IEC 2382:2015 Information technology -- Vocabulary) Example: storage devices, input-output units, one or more processing units, data, files, and programs


computer resource allocation. (1) assignment of computer resources to current and waiting jobs (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Example: the assignment of main memory, input/output devices, and auxiliary storage to jobs executing concurrently in a computer system See Also: dynamic resource allocation, storage allocation


computer resources. (1) computer equipment, programs, documentation, services, facilities, supplies, and personnel available for a given purpose (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: computer resource allocation


computer science. (1) branch of science and technology that is concerned with information processing by means of computers (ISO/IEC 2382:2015 Information technology -- Vocabulary)


computer software component (CSC). (1) functionally or logically distinct part of a computer software configuration item, typically an aggregate of two or more software units (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: computer software configuration item, software configuration item, software item


computer software configuration item (CSCI). (1) aggregation of software that is designated for configuration management and treated as a single entity in the configuration management process (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Syn: software configuration item (SWCI) See Also: computer software component, hardware configuration item, configuration item, software configuration item, software item


computer system. (1) system containing one or more computers and associated software (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) system containing one or more components and elements such as computers (hardware), associated software, and data (ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.3) Syn: computing system See Also: data processing system


computer-aided (CA). (1) pertaining to a technique or process in which a computer does part of the work (ISO/IEC 2382:2015 Information technology -- Vocabulary)


computer-aided design (CAD). (1) use of a computer to design a device or a system, display it on a computer monitor or printer, simulate its operation, and provide statistics on its performance (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: The computer is provided with data concerning the item to be designed, how it is to function, and the rules for the way in which the different components can be joined.


computer-aided software engineering (CASE). (1) use of computers to aid in the software engineering process (ISO/IEC 15940:2013 Systems and software engineering--Software Engineering Environment Services, 2.2) Example: application of software tools to software design, requirements tracing, code production, testing, document generation, and other software engineering activities Syn: computer aided software engineering See Also: integrated development environment


computer-based software system (CBSS). (1) software system running on a computer (ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.5) Example: null Note: A CBSS can be a data processing system as seen by human users at their terminals or at equivalent machine-user-interfaces. It includes hardware and all software (system software and application software) which is necessary for realizing data processing functions required by its users


computerization. (1) automation by means of computers (ISO/IEC 2382:2015 Information technology -- Vocabulary)


computerize. (1) to automate by means of computers (ISO/IEC 2382:2015 Information technology -- Vocabulary)


computing center. (1) facility designed to provide computer services to a variety of users through the operation of computers and auxiliary hardware and through services provided by the facility's staff (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


computing device. (1) functional unit that can perform substantial computations, including numerous arithmetic operations and logic operations, with or without human intervention (ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.6) Note: A computing device can consist of a stand-alone unit, or several interconnected units. It can also be a device that provides a specific set of functions, such as a phone or a personal organizer, or more general functions such as a laptop or desktop computer. See Also: computer


COMSEC. (1) communications security (IEEE 15288.2:2014 IEEE Standard for Technical Reviews and Audits on Defense Programs, 3.2)


concept analysis. (1) derivation of a system concept through the application of analysis (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: analysis


concept of operations. (1) verbal or graphic statement, in broad outline, of an organization's assumptions or intent in regard to an operation or series of operations (ISO/IEC/IEEE 12207:2017 Systems and software engineering--Software life cycle processes, 3.1.13) (ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.1.4) (ISO/IEC/IEEE 15288:2015 Systems and software engineering--System life cycle processes, 4.1.11) (ISO/IEC/IEEE 24748-1:2018 Systems and software engineering--Life cycle management--Part 1: Guidelines for life cycle management, 2.12) Note: It provides the basis for bounding the operating space, system capabilities, interfaces and operating environment. The concept of operations frequently is embodied in long-range strategic plans and annual operational plans. In the latter case, the concept of operations in the plan covers a series of connected operations to be carried out simultaneously or in succession. The concept is designed to give an overall picture of the organization operations. Syn: ConOps, CONOPS See Also: operational concept


concept of operations (ConOps) document. (1) user-oriented document that describes a system's operational characteristics from the end user's viewpoint (ISO/IEC/IEEE 24765e:2015) See Also: operational concept description (OCD)


concept phase. (1) period of time in the system life cycle during which the user needs are identified and system concepts are described and evaluated (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: precedes the requirements phase


conceptual data model. (1) a data model that illustrates the data groups as they are seen by the user (ISO/IEC 24570:2005 Software engineering -- NESMA functional size measurement method version 2.1 -- Definitions and counting guidelines for the application of Function Point Analysis)


conceptual model. (1) model of the concepts relevant to some endeavor (IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.39)


conceptual system design. (1) system design activity concerned with specifying the logical aspects of the system organization, its processes, and the flow of information through the system (ISO/IEC 2382:2015 Information technology -- Vocabulary)


concern. (1) [system] interest in a system relevant to one or more of its stakeholders (ISO/IEC/IEEE 12207:2017 Systems and software engineering--Software life cycle processes, 3.1.14) (ISO/IEC/IEEE 42010:2011 Systems and software engineering--Architecture description, 3.7) (ISO/IEC/IEEE 15288:2015 Systems and software engineering--System life cycle processes, 4.1.12) (ISO/IEC/IEEE 24748-1:2018 Systems and software engineering--Life cycle management--Part 1: Guidelines for life cycle management, 2.13) (2) interest in something relevant to one or more of its stakeholders (ISO/IEC TR 12182:2015 Systems and software engineering--Framework for categorization of IT systems and software, and guide for applying it, 3.2) (3) matter of interest or importance to a stakeholder (ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.8) Example: Affordability, agility, availability, dependability, flexibility, maintainability, reliability, resilience, usability and viability are examples of concerns. Survivability, depletion, degradation, loss, obsolescence are examples of concerns. The PESTEL mnemonic is a reminder of possible areas of concern: political, economic, social, technological, environmental, and legal. Note: A concern pertains to any influence on a system in its environment, including developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences.


conciseness. (1) software attributes that provide implementation of a function with a minimum amount of code (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


concurrency. (1) property of a system in which events can occur independently of each other, and hence are not ordered (ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.6) See Also: step


concurrent. (1) pertaining to the occurrence of two or more activities within the same interval of time, achieved either by interleaving the activities or by simultaneous execution (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) problem, process, system, or application in which many activities happen in parallel, the order of incoming events is not usually predictable, and events often overlap (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: A concurrent system or application has many threads of control. See Also: parallel, simultaneous


concurrent communication diagram. (1) diagram depicting a network of concurrent tasks and their interfaces in the form of asynchronous and synchronous message communication, event synchronization, and access to passive information-hiding objects (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


concurrent elaboration. (1) life cycle process instances are enacted concurrently during the project, and the information items and artifacts produced by these process instances evolve concurrently (ISO/IEC 30103:2015 Software and Systems Engineering - Lifecycle Processes - Framework for Product Quality Achievement, 3.1) Note: This is referred to as concurrent elaboration of information items.


concurrent enabling (of transition modes). (1) state, for a multiset of transition modes, when all the involved input places contain enough tokens to satisfy the sum of all of the demands imposed on them by each input arc annotation evaluated for each transition mode in the multiset (ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.5)


concurrent task architecture. (1) description of the concurrent tasks in a system or subsystem in terms of their interfaces and interconnections (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


condition. (1) measurable qualitative or quantitative attribute that is stipulated for a requirement and that indicates a circumstance or event under which a requirement applies (ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.1.5) (2) description of a contingency to be considered in the representation of a problem, or a reference to other procedures to be considered as part of the condition (ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.6) (3) Boolean expression containing no Boolean operators (ISO/IEC/IEEE 29119-4:2015 Software and systems engineering -- Software testing -- Part 4: Test techniques, 4.6)


condition entry. (1) indication of the relevance of a condition to a particular rule (ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.8)


condition stub. (1) list of all the conditions to be considered in the description of a problem (ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.1)


conditional information. (1) information supplied with every product to which it is relevant (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)


conditional jump. (1) jump that takes place only when specified conditions are met (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: unconditional jump


conditional process. (1) process that can be mandatory under some specified conditions, can be optional under other specified conditions, and can be out of scope or not