Metrics Glossary

Software Metrics Glossary - A

abend

abbreviation for abnormal end.

 ISO/IEC 24765, Systems and Software Engineering Vocabulary

abnormal end(abend)

 termination of a process prior to completion.  See also: abort, exception.

ISO/IEC 24765, Systems and Software Engineering Vocabulary

 Abort

to terminate a process prior to completion.  See also: abend, exception.

ISO/IEC 24765, Systems and Software Engineering Vocabulary

Absolute address

 an 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.  Syn: explicit address, specific address. See also: relative address, relocatable address, symbolic address, absolute assembler, absolute code, absolute instruction.  

ISO/IEC 24765, Systems and Software Engineering Vocabulary

 Absolute assembler

an assembler that produces absolute code.  See also: relocating assembler.
ISO/IEC 24765, Systems and Software Engineering Vocabulary
 Absolute code

code in which all addresses are absolute addresses. 

Syn: specific code. See also: relocatable code.

ISO/IEC 24765, Systems and Software Engineering Vocabulary

 Absolute instruction

a computer instruction in which all addresses are absolute addresses. See also: direct instruction, effective instruction, immediate instruction, indirect instruction.
ISO/IEC 24765, Systems and Software Engineering Vocabulary.

 Abstract class

a class that cannot be instantiated independently.

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.
IEEE 1320.2-1998 (R2004) IEEE
Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject). 3.1.1.

 Abstract date type

a 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 24765, Systems and Software Engineering Vocabulary.

 Abstract design

1. a generic form that needs specialization (further design work) to produce concrete designs.  2. design aimed at producing designs. ISO/IEC 24765, Systems and Software Engineering Vocabulary.
 Abstraction
1.a view of an object that focuses on the information relevant to a particular purpose and ignores the remainder of the information. 2.the process of formulating a view.  See also: data abstraction.
ISO/IEC 24765, Systems and Software Engineering Vocabulary.

 Accept

the act of formally receiving or acknowledging something and regarding it as being true, sound, suitable, or complete.
 A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Third Edition.

 Acceptability

the exposure to loss (financial or otherwise) that an organization is willing to tolerate from a risk. Note: Risk acceptability may apply to an individual risk or to a collection of risks, such as the totality of risks confronting a project or enterprise. Acceptability may differ for different categories of risk and may depend on the cost of treatment or other factors.

 
IEEE 1540-2001 IEEE Standard for Software Life Cycle Processes-Risk Management.

3.10.

 Acceptance criteria

1. the criteria that a system or component must satisfy in order to be accepted by a user,customer, or other authorized entity.  2. those criteria, including performance requirements and essential conditions, which must be met before project deliverables are accepted. See also: requirement, test criteria.
 ISO/IEC 24765, Systems and Software Engineering Vocabulary. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Third Edition.

 Acceptance test

1. the test of a system or functional unit usually performed by the purchaser on his premises after installation with the participation of the vendor to ensure that the contractual requirements are met.
 ISO/IEC 2382-20:1990 Information technology--Vocabulary--Part 20: System development. 20.05.07.

 Acceptance testing

1. formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.  2. formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a system or component.
 IEEE 1012- 
2004 IEEE Standard for Software Verification and Validation. 3.1.1

Access

 to obtain the use of a resource. ISO/IEC 2382-1:1993 Information technology--Vocabulary--Part 1:  Fundamental terms. 01.01.04.

Access facility

1. a 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
a 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-1:1993 Information technology--Vocabulary-Part 1: Fundamental terms. 01.08.03.

Access routine

a 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 24765, Systems and Software Engineering Vocabulary.
Access transparency

1. a distribution transparency which masks differences in data representation and invocation mechanisms to enable interworking between objects.

 ISO/IEC 10746-3:1996 Information technology -- Open Distributed Processing -- Reference Model: Architecture. 4.4.1.1.

Accessibility

1. successful access to information and use of information technology by people who have disabilities. . 2.usability of a product, service, environment or facility by people with the widest range of capabilities.

NOTE:Although "accessibility" typically addresses users who have disabilities, the concept is not limited to disability issues.
ISO/IEC 18019:2004 Software and system engineering - Guidelines for the design and preparation of user documentation for application software

ISO/IEC 25062:2006 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Common Industry Format (CIF) for usability test reports. 4.10

A posteriori verification method

Verification method applicable on the results provided by an FSM method

( Reference : ISO/IEC JTC1/SC7:14143-3)

A priori verification method

Verification method applicable on the (design of the) FSM method (by opposition with verification methods applicable on the results provided by the FSM method).

( Reference : ISO/IEC JTC1/SC7:14143-3)

acceptance criteria

The criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity [IEEE-STD-610].

( Reference : SEI:SA-CMM)

 ACD

Automatic Call Distribution

( Reference ITIL® Sept 2002)

accident

1. an 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 (2002) IEEE Standard for Software Safety Plans.3.1.1

Accountability Matrix

See responsibility assignment matrix.

( Reference : PMI:PMBOK)

Accuracy

The ability of an FSM Method to give a Functional Size measurement scale which by verification tests can be shown to be a consistent scale for sizing any Functional User Requirements from specific Functional Domains, that is a scale which is verified within certain established limits of random and systematic errors.

( Reference : ISO/IEC JTC1/SC7:14143-3)

Accuracy of measurement

the closeness of the agreement between the result of a measurement and the true value of the measurand.

Note: Accuracy is a qualitative concept. The term precision should not be used for "accuracy". Internationalvocabulary of basic and general terms in metrology, 1993, definition 3.5] A true value, as defined in the ISO Vocabulary of basic and general terms in metrology (1993), 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 should be expressed in terms of the Mean magnitude of relative error.

ISO/IEC TR 14143-3:2003 Information technology -- Software measurement --
 

Functional size measurement -- Part 3: Verification of functional size measurement methods. 3.10

Acquirer

An organization that acquires or procures a system, software product or software service from a supplier.

( Reference : ISO/IEC JTC1/SC7:12207)

Acquirer

A party, commonly an enterprise, that acquires or procures a system or a component of the system from a supplier. Note - The acquirer could be termed a buyer, customer, owner, user, purchaser.

( Reference : SC7/WG7:15288)

acquirer

An organisation that acquires or procures a system, software product, or software service from a supplier.

 Reference : [ISO/IEC 12207: 1995SC7:15939

Acquisition

The process of obtaining a system, software product or software service.

( Reference : ISO/IEC JTC1/SC7:12207)

acquisition organization

That entity which has the oversight responsibility for the software acquisition project and which may have purview over the acquisition activities of a number of projects or contract actions.

( Reference : SEI:SA-CMM)

 acquisition strategy

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 24765, Systems and Software Engineering Vocabulary.

acquisition organization's standard software acquisition process

The acquisition organization's fundamental software acquisition process which guides the establishment of each project's defined software acquisition process.

( Reference : SEI:SA-CMM)

 action

element of a step that a user performs to complete a procedure

IEEE 1063-2001 IEEE Standard for Software User Documentation.
 action a 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.
 action entry
an 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

an action in a transaction which leads to a state change of significance to the transaction.

 ISO/IEC 10746-3:1996 Information technology -- Open Distributed Processing -- Reference
 Model: Architecture. 13.7.1.2.

action proposal

A documented suggestion for change to a process or process-related item that will prevent the future occurrence of defects identified as a result of defect prevention activities. (See also software process improvement proposal.)

( Reference : SEI:SW-CMM)

action stub

a 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.

activities performed

A description of the tasks necessary to implement a key process area. Activities Performed typically involve establishing plans and procedures, performing the work, tracking it, and taking corrective actions as necessary. [Jones - IBM]

( Reference : SEI:SE-CMM)

activity

all or part of functionality

( Reference : TC184/SC5:15704)

activity

Any step taken or function performed, either mental or physical, toward achieving some objective. Activities include all the work the managers and technical staff do to perform the tasks of the project and organization.

( Reference : SEI:SA-CMM)

activity

 set of cohesive tasks of a process  ISO/IEC 12207:2008 Systems and software engineering--Software life cycle processes. 4.3, ISO/IEC 15288:2008 Systems and software engineering--System life cycle processes. 4.3.

activity

a component of work performed during the course of a project.
 A Guide to the Project
 

Management Body of Knowledge (PMBOK® Guide) -- Third Edition.

activity

an 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.10.

activity

a defined body of work to be performed, including its required input information and output information.

 IEEE 1074-2006 IEEE Standard for Developing a Software Project Life Cycle Process. Annex E.

activity

collection of related tasks. ISO/IEC 9003:2004 Software engineering -- Guidelines for the
 application of ISO 9001:2000 to computer software.3.10. 

activity attributes

[Output/Input] 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® Guide) -- Third Edition.

activity code

one or more numerical or text values that identify characteristics of the work or in some way categorize the schedule activity that allows filtering and ordering of activities within reports.

 A Guide to the
 Project Management Body of Knowledge (PMBOK® Guide) -- Third Edition.

activity definition

[Process] the process of identifying the specific schedule activities that need to be performed to produce the various project deliverables.


A Guide to the Project Management Body of
 Knowledge (PMBOK® Guide) -- Third Edition.
 activity description (AD) [Process] the process of identifying the specific schedule activities that need to be performed to produce the various project deliverables. .  A Guide to the Project Management Body of
 

Knowledge (PMBOK® Guide) -- Third Edition

activity duration the time in calendar units between the start and finish of a schedule activity. See also: actual duration,original duration, remaining duration. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Third Edition.
activity duration estimates

Estimating the number of work periods which will be needed to complete individual activities.

( Reference : PMI:PMBOK

 activity group
a set of related activities.  
 IEEE 1074-2006 IEEE Standard for Developing a Software Project Life Cycle Process. Annex E.
activity identifier  a short unique numeric or text identification assigned to each schedule activity to differentiate that project activity from other activities. Typically unique within any one project schedule network
 

diagram.

 A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Third Edition.
activity list

[Output/Input] 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®
 

Guide) -- Third Edition.

activity resourse estimating [Process] the process of estimating the types and quantities of resources required to perform each schedule activity.  Syn: resource planning.
A Guide to the Project Management Body of Knowledge
 

(PMBOK® Guide) -- Third Edition.

activity sequencing [Process] the process of identifying and documenting dependencies among schedule  

activities.

 A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Third Edition
activity type

a 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.20

activation

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 contraint

a 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.
activative area

area of a screen interface that responds to user input.

 ISO/IEC 18019:2004 Software and system engineering - Guidelines for the design and preparation of user documentation for application  software. 2.20.

Activity Definition

Identifying the specific activities that must be performed in order to produce the various project deliverables.

( Reference : PMI:PMBOK)

 

Active interconnection 

a physical interaction mechanism allowing the action of one thing to cause a change or to stimulate an action in another thing.

IEEE 1175.2-2006 IEEE Recommended Practice for CASE Tool Interconnection--Characterization of Interconnections. 3.10.
 Active redundancy
in fault tolerance, the use of redundant elements operating simultaneously to prevent,or permit recovery from, failures.  See also: standby redundancy.
 ISO/IEC 24765, Systems and Software Engineering Vocabulary.
Active text

text displayed on the screen that responds to user input.

 ISO/IEC 18019:2004 Software and system engineering - Guidelines for the design and preparation of user documentation for application

software.2.3

Active white space

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 15910:1999 Information technology -- Software user documentation process.4.54

Activity Duration Estimating

Estimating the number of work periods which will be needed to complete individual activities.

( Reference : PMI:PMBOK)

 Actual Cost (AC)

total costs actually incurred and recorded in accomplishing work performed for a schedule activity or work breakdown structure component. Actual cost can sometimes be direct labor hours
 alone, direct costs alone, or all costs including indirect costs. See also: earned value management, earned value technique.
Syn: actual cost of work performed (ACWP).
Guide to the Project Management Body of  

Knowledge (PMBOK® Guide) -- Third Edition.

Actual Cost of Work Performed (ACWP)

Total costs incurred (direct and indirect) in accomplishing work during a given time period. See also earned value

( Reference : PMI:PMBOK)

 Actual duration

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® Guide) --Third Edition.

Actual Finish Date (AF)

The point in time that work actually ended on an activity. (Note: in some application areas, the activity is considered "finished" when work is "substantially complete.")

( Reference : PMI:PMBOK)

Actual Start Date (AS)

The point in time that work actually started on an activity.

( Reference : PMI:PMBOK)

 ACWP

Actual Cost of Work Performed.

 A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Third Edition.
 Actor

a role (with respect to that action) in which the enterprise object fulfilling the role participates in the action

 ISO/IEC 15414:2006 Information technology -- Open distributed processing -- Reference model --Enterprise language.6.3.1.
Actor organization or CASE tool that supplies and/or acquires SEE Services ISO/IEC 15940:2006 Information Technology -- Software Engineering Environment Services. 2.2.4
Actor  in UML,someone or something outside the system that interacts with the system. ISO/IEC 24765, Systems and Software Engineering Vocabulary.
 AD

 Activity Description.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Third Edition.

 Adaptation data

 data used to adapt a program to a given installation site or to given conditions in its operational environment. ISO/IEC 24765, Systems and Software Engineering Vocabulary.
Adaptation parameter

a variable that is given a specific value to adapt a program to a given installation site or to given conditions in its operational environment.


EXAMPLE 

the variable Installation_Site_Latitude

ISO/IEC 24765, Systems and Software Engineering Vocabulary.
 Adaptater

an object adapter.


ISO/IEC 19500-2:2003 Information technology -- Open Distributed Processing -- Part 2: General Inter-ORB Protocol (GIOP)/Internet Inter-ORB Protocol (IIOP). 3.2.1.

Adaptive Maintenance

modification of a software product, performed after delivery, to keep a software product usable in a changed or changing environment.
 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. For example, the operating system might be upgraded and some changes may be made to accommodate the new operating system
IEEE 14764-2006 Software Engineering - Software Life Cycle Processes - Maintenance. 3.10.
Added source statements the count of source statements that were created specifically for the software product ISO/IEC 24765, Systems and Software Engineering Vocabulary.
 Address a number, character, or group of characters that identifies a given device or storage location ISO/IEC 24765, Systems and Software Engineering Vocabulary.
 Address to refer to a device or storage location by an identifying number, character, or group of characters  ISO/IEC 24765, Systems and Software Engineering Vocabulary.
 Address field a field of a computer instruction that contains addresses, information necessary to derive addresses, or values of operands.Syn: address part. See also: operation field ISO/IEC 24765, Systems and Software Engineering Vocabulary. 
 Address format  the number and arrangement of address fields in a computer instruction  ISO/IEC 24765,
 

Systems and Software Engineering Vocabulary

  Address format the 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.See also: n-address instruction, n-plus-one address instruction.


ISO/IEC 24765, Systems and Software Engineering Vocabulary.
 Address modification an arithmetic, logical, or syntactic operation performed on an address
See also: effective address, indexed address, relative

address, relocatable address.

ISO/IEC 24765, Systems and Software Engineering Vocabulary.
 Address space

the addresses that a computer program can access.

ISO/IEC 24765, Systems and
 

Software Engineering Vocabulary.

 Address space

the number of memory locations that a central processing unit can address.
 NOTE: In some systems, this may be 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 may be accessible by other programs.
ISO/IEC 24765, Systems and Software Engineering Vocabulary.

 Addressing expetion

an exception that occurs when a program calculates an address outside the bounds of the storage available to it. See also: data exception, operation exception, overflow exception, protection exception, underflow exception. ISO/IEC 24765, Systems and Software Engineering Vocabulary 
Adjusted function point count (AFP) the unadjusted function point count multiplied by the value adjustment factor.  ISO/IEC 20926:2003 Software engineering -- IFPUG 4.1 Unadjusted functional size
 measurement method -- Counting practices manual.

Administrative Closure

Generating, gathering, and disseminating information to formalize project completion.

( Reference : PMI:PMBOK)

Adoption process

The set of activities by which an organization brings CASE tools into widespread use.

( Reference : ISO/IEC JTC1/SC7:14471)

allocation

(1) The process of distributing requirements, resources, or other entities among the components of a system or program. (2) The results of the distribution in (1). [IEEE STD 610.12-1990]

( Reference : SEI:SE-CMM)

Applicability to a functional domain

The ability of an FSM Method to take into account the principle Functional Size-influencing FUR types and characteristics (i.e. the Base Functional Components) of a Functional Domain.

( Reference : ISO/IEC JTC1/SC7:14143-3)

Application

Is used synonymously for ‘software system’. It is assumed that an organisation will develop and maintain one or more software applications which will be sized using Function Point Analysis. Each set of activities which impacts the system software is called a project. Application Counts measure the size of the implemented software product.

( Reference : Total Metrics)

Application Area

A category of projects that have common elements not present in all projects. Application areas are usually defined in terms of either the product of the project (i.e., by similar technologies or industry sectors) or the type of customer (e.g., internal vs. external, government vs. commercial). Application areas often overlap.

( Reference : PMI:PMBOK)

Application Baseline Function Point Count

A function point count that provides a measure of the current function the production application provides the end-user. It is also referred to as the installed function point count.

( Reference : Total Metrics)

Application Boundary

The application boundary indicates the border between the software being measured and the user.

( Reference : IFPUG CPM 4.1)

application domain

A bounded set of related systems, i.e., systems that address a particular type of problem. Development and maintenance in an application domain usually requires special skills and/or resources. Examples include payroll and personnel systems, command and control systems, compilers, and expert systems. [CMM for Software]

( Reference : SEI:SE-CMM)

Application function point count

A count that provides a measure of the current functionality the application provides to the user. It is also referred to as a baseline or installed function point count.

( Reference : IFPUG CPM 4.1)

Application manager

A person responsible for managing projects and support activities for one or more application areas.

( Reference : IFPUG CPM 4.1)

application problem

A problem submitted by an end user and requiring information processing for its solution.

( Reference : ISO/IEC JTC1/SC1:2382-20)

Application Register

A repository of information about applications within the organisation’s software portfolio often used to assist with the scheduling of function point counting activity.

( Reference : Total Metrics)

application software [program]

A software [program! that is specific to the solution of an application problem.

( Reference : ISO/IEC JTC1/SC1:2382-20)

appraisal

A comparison of an implemented process to a process maturity model Software process assessments and software capability evaluations are examples. [Bate - SEI]

( Reference : SEI:SE-CMM)

approved modification

The disposition of one or more proposed changes authorising revision of one or more SCIs.

( Reference : SC7/WG8:15846)

architecture

The organizational structure of a system or component. [IEEE STD 610.12-1990]

( Reference : SEI:SE-CMM)

Arity

The arity (of a relationship) is the number of roles that participate in a relationship. 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.

( Reference : ISO/IEC JTC1/SC7; CDIF:15474-1)

assessed capability

the output of one or more recent, relevant process assessments conducted in accordance with the provisions of ISO/IEC 15504

( Reference : ISO/IEC JTC1/SC7:15504-9)

assessment constraints

restrictions placed on the freedom of choice of the assessment team regarding the conduct of the assessment and the use of the assessment outputs.

( Reference : ISO/IEC JTC1/SC7:15504-9)

assessment indicator

An objective attribute or characteristic of a practice or work product that supports the evaluation of the performance of, or capability of, an implemented process.

( Reference : INUSE:UMM)

assessment input

the collection of information required before a process assessment can commence

( Reference : ISO/IEC JTC1/SC7:15504-9)

assessment instrument

a tool or set of tools that is used throughout an assessment to assist the assessor in evaluating the performance or capability of processes and in handling assessment data and recording the assessment results

( Reference : ISO/IEC JTC1/SC7:15504-9)

assessment output

all of the tangible results from an assessment (see assessment record)

( Reference : ISO/IEC JTC1/SC7:15504-9)

assessment participant

an individual who has responsibilities within the scope of the assessment

( Reference : ISO/IEC JTC1/SC7:15504-9)

assessment purpose

a statement, provided as part of the assessment input, which defines the reason for performing the assessment

( Reference : ISO/IEC JTC1/SC7:15504-9)

assessment record

an orderly, documented collection of that information which is pertinent to the assessment and adds to the understanding and verification of the process profiles generated by the assessment

( Reference : ISO/IEC JTC1/SC7:15504-9)

assessment scope

a definition of the boundaries of the assessment, provided as part of the assessment input, encompassing the organizational limits of the assessment, the processes to be included, and the context within which the processes operate (see process context)

( Reference : ISO/IEC JTC1/SC7:15504-9)

assessment sponsor

the individual, internal or external to the organization being assessed, who requires the assessment to be performed, and provides financial or other resources to carry it out

( Reference : ISO/IEC JTC1/SC7:15504-9)

asset

An item, such as design, documentation, specifications, source code, documentation, test suites, etc., that has been designed for use in multiple contexts.

( Reference : IEEE SESC:729)

Asset

(1) A capital asset of the enterprise. (2) An advantage or resource.

( Reference : IFPUG CPM 4.1)

Associative Entity

An entity used to represent a relationship between other entities. An Associative Entity is used when a relationship does not otherwise provide sufficient mechanisms.

( Reference : ISO/IEC JTC1/SC7; CDIF:15474-1)

Associative entity type

An entity type that contains attributes which further describe a many-to-many relationship between two other entity types. See also Entity type.

( Reference : IFPUG CPM 4.1)

attribute

a measurable physical or abstract property of an entity

( Reference : ISO/IEC JTC1/SC7:14598-1)

Attribute

A single-valued characteristic of an entity or relationship. 39

( Reference : ISO/IEC JTC1/SC7; CDIF:15474-1)

Attribute

a piece of information stating a property of an entity

( Reference : TC184/SC5:15704)

Attribute

A measurable physical or abstract property of an entity. [ISO/IEC 14598-1: 1996]

( Reference : SC7:15939)

Attribute

A characteristic of an item; for example, the item’s color, size, or type. [IEEE STD 610.12-1990]

( Reference : SEI:SE-CMM)

Attribute

See Project/application attribute and Data attribute.

( Reference : IFPUG CPM 4.1)

attribute indicator

an assessment indicator that supports the judgment of the extent of achievement of a specific process attribute

( Reference : ISO/IEC JTC1/SC7:15504-5)

attributes (of software)

Characteristics of software such as reliability, maintainability, portability, and complexity. These characteristics are sometimes referred to as quality attributes.

( Reference : SEI:SA-CMM)

Attributive entity type

An entity type that further describes one or more attributes of another entity type. See also Entity.

( Reference : IFPUG CPM 4.1)

Audience

category of users sharing the same or similar characteristics and needs (e.g. purpose in using the documentation, tasks, education level, abilities, training, experience) that determine the content, structure and use of the intended documentation NOTE There may be a number of different audiences for a software product's documentation (e.g. management, data entry, maintenance).

( Reference : ISO/IEC JTC1/SC7:15910)

audience research

planned process of interview, and of the analysis of interview records and personnel records NOTE The purpose of audience research is to determine the abilities, training, experience, limitations, prejudices and preferences of the intended readers of a

document.

( Reference : ISO/IEC JTC1/SC7:15910)

audit

systematic and objective activity to find out the extent to which requirements related to an agreed subject matter are fulfilled, performed by one or more persons who are independent of that which is audited NOTE 1 - The requirements may include determining whether the subject matter of the audit has been effectively implemented, and planned arrangements are complied with. NOTE 2 - Information is collected during the audit. NOTE 3 - Verified information becomes objective evidence (4.7.2). NOTE 4 - Objective evidence (4.7.2), which is considered significant, becomes an audit finding. NOTE 5 - The audit report contains a summary of the audit findings and any conclusions that may be drawn from the findings. NOTE 6 - Audit reports are used as input to reviews (4.6.5). NOTE 7 - An audit may be performed by an audit team (4.6.9) which may contain auditors, technical experts, observers and guides, or by a single auditor possessing the competencies necessary to complete the audit.

( Reference : TC176:ISO 9000:2000)

Audit

Conducted by an authorized person for the purpose of providing an independent assessment of software products and processes in order to assess compliance with requirements.

( Reference : ISO/IEC JTC1/SC7:12207)

audit

An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria. [IEEE STD 610.12-1990]

( Reference : SEI:SE-CMM)

audit client

person or organization (4.2.1) commissioning the audit (4.6.7)

( Reference : TC176:ISO 9000:2000)

audit team

one, or more, auditors (4.6.8) designated to perform an audit (4.6.7)

( Reference : TC176:ISO 9000:2000)

auditee

person or organization (4.2.1) being audited

( Reference : TC176:ISO 9000:2000)

auditor

person who performs an audit (4.6.7) NOTE - A person who performs an audit (4.6.7) should be competent or qualified to do so. The word "qualified" bears its ordinary dictionary meaning.

(Reference : TC176:ISO 9000:2000)

vailability

Ability of a component or service to perform its required function at a stated instant or over a stated period of time. It is usually expressed as the availability ratio, i.e. the proportion of time that the service is actually available for use by the Customers within the agreed service hours.