Glossaire des termes en informatique
jeudi 20 mars 2003, par
Définitions en Anglais de termes à connaître dans le domaine de l’informatique et particulièrement coté développement et programmation.
|Abstractness||the degree to which a system or component performs only the necessary functions relevant to a particular purpose.|
|Acceptance testing||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 [IEEE 90].|
|Accessibility||(Denial of Service) the degree to which the software system protects system functions or service from being denied to the user |
(Reusability) the degree to which a software system or component facilitates the selective use of its components [Boehm 78].
|Accountability||the ability of a system to keep track of who or what accessed and/or made changes to the system.|
|Accuracy||a quantitative measure of the magnitude of error [IEEE 90].|
|Acquisition cycle time||the period of time that starts when a system is conceived and ends when the product meets its initial operational capability.|
|Adaptability||the ease with which software satisfies differing system constraints and user needs [Evans 87].|
|Adaptive maintenance||software maintenance performed to make a computer program usable in a changed environment [IEEE 90].|
|Adaptive measures||a category of quality measures that address how easily a system can evolve or migrate.|
|Agent||a piece of software which acts to accomplish tasks on behalf of its user [McGill 96].|
|Anonymity||the degree to which a software system or component allows for or supports anonymous transactions.|
|Application program interface||a formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services [ITS 96].|
|Architectural design||the process of defining a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system [IEEE 90].|
|Artificial intelligence||a subfield within computer science concerned with developing technology to enable computers to solve problems (or assist humans in solving problems) using explicit representations of knowledge and reasoning methods employing that knowledge [DoD 91].|
|Auditable||the degree to which a software system records information concerning transactions performed against the system.|
|Availability||the degree to which a system or component is operational and accessible when required for use [IEEE 90].|
|Capacity||a measure of the amount of work a system can perform [Barbacci 95].|
|Code||the transforming of logic and data from design specifications (design descriptions) into a programming language [IEEE 90].|
|Commonality||the degree to which standards are used to achieve interoperability.|
|Communication software||software concerned with the representation, transfer, interpretation, and processing of data among computer systems or networks.|
The meaning assigned to the data must be preserved during these operations.
|Compactness||the degree to which a system or component makes efficient use of its data storage space occupies a small volume.|
|Compatibility||the ability of two or more systems or components to perform their required functions while sharing the same hardware or software environment [IEEE 90].|
|Completeness||the degree to which all the parts of a software system or component are present and each of its parts is fully specified and developed [Boehm 78].|
|Complexity||(Apparent) the degree to which a system or component has a design or implementation that is difficult to understand and verify [IEEE 90].|
(Inherent) the degree of complication of a system or system component, determined by such factors as the number and intricacy of interfaces, the number and intricacy of conditional branches, the degree of nesting, and the types of data structures [Evans 87].
|Component testing||testing of individual hardware or software components or groups of related components [IEEE 90].|
|Concept phase||the initial phase of a software development project, in which the user needs are described and evaluated through documentation (for example, statement of needs, advance planning report, project initiation memo, feasibility studies, system definition, documentation, regulations, procedures, or policies relevant to the project) [IEEE 90].|
|Conciseness||the degree to which a software system or component has no excessive information present.|
|Confidentiality||the nonoccurrence of the unauthorized disclosure of information [Barbacci 95].|
|Consistency||the degree of uniformity, standardization, and freedom from contradiction among the documents or parts of a system or component [IEEE 90].|
|Corrective maintenance||maintenance performed to correct faults in hardware or software [IEEE 90].|
|Correctness||the degree to which a system or component is free from faults in its specification, design, and implementation [IEEE 90].|
|Cost estimation||the process of estimating the "costs" associated with software development projects, to include the effort, time, and labor required.|
|Cost of maintenance||the overall cost of maintaining a computer system to include the costs associated with personnel, training, maintenance control, hardware and software maintenance, and requirements growth.|
|Cost of operation||the overall cost of operating a computer system to include the costs associated with personnel, training, and system operations.|
|Cost of ownership||the overall cost of a computer system to an organization to include the costs associated with operating and maintaining the system, and the lifetime of operational use of the system|
|Data management||the function that provides access to data, performs or monitors the storage of data, and controls input/output operations [McDaniel 94].|
|Data management security||the protection of data from unauthorized (accidental or intentional) modification, destruction, or disclosure [ITS 96].|
|Data recording||to register all or selected activities of a computer system.|
Can include both external and internal activity.
|Data reduction||any technique used to transform data from raw data into a more useful form of data.|
For example, grouping, summing, or averaging related data [IEEE 90].
|Database||1 a collection of logically related data stored together in one or more computerized files.|
Note : Each data item is identified by one or more keys [IEEE 90].
2 an electronic repository of information accessible via a query language interface [DoD 91].
|Database administration||the responsibility for the definition, operation, protection, performance, and recovery of a database [IEEE 90].|
|Database design||the process of developing a database that will meet a user’s requirements.|
The activity includes three separate but dependent steps : conceptual database design, logical database design, and physical database design [IEEE 91].
|Denial of service||the degree to which a software system or component prevents the interference or disruption of system services to the user.|
|Dependability||that property of a computer system such that reliance can justifiably be placed on the service it delivers [Barbacci 95].|
|Design phase||the period of time in the software life cycle during which the designs for architecture, software components, interfaces, and data are created, documented, and verified to satisfy requirements [IEEE 90].|
|Detailed design||the process of refining and expanding the preliminary design of a system or component to the extent that the design is sufficiently complete to be implemented [IEEE 90].|
|Distributed computing||a computer system in which several interconnected computers share the computing tasks assigned to the system [IEEE 90].|
|Domain analysis||the activity that determines the common requirements within a domain for the purpose of identifying reuse opportunities among the systems in the domain.|
It builds a domain architectural model representing the commonalities and differences in requirements within the domain (problem space) [ARC 96].
|Domain design||the activity that takes the results of domain analysis to identify and generalize solutions for those common requirements in the form of a Domain Specific Software Architecture (DSSA).|
It focuses on the problem space, not just on a particular system’s requirements, to design a solution (solution space) [ARC 96].
|Domain engineering||the process of analysis, specification and implementation of software assets in a domain which are used in the development of multiple software products [SEI 96].|
The three main activities of domain engineering are : domain analysis, domain design, and domain implementation [ARC 96].
|Domain implementation||the activity that realizes the reuse opportunities identified during domain analysis and design in the form of common requirements and design solutions, respectively.|
It facilitates the integration of those reusable assets into a particular application [ARC 96].
|Effectiveness||the degree to which a system’s features and capabilities meet the user’s needs.|
|Efficiency||the degree to which a system or component performs its designated functions with minimum consumption of resources (CPU, Memory, I/O, Peripherals, Networks) [IEEE 90].|
|Error handling||the function of a computer system or component that identifies and responds to user or system errors to maintain normal or at the very least degraded operations.|
|Error proneness||the degree to which a system may allow the user to intentionally or unintentionally introduce errors into or misuse the system.|
|Error tolerance||the ability of a system or component to continue normal operation despite the presence of erroneous inputs [IEEE 90].|
|Evolvability||the ease with which a system or component can be modified to take advantage of new software or hardware technologies.|
|Expandability||see Extendability [IEEE 90].|
|Extendability||the ease with which a system or component can be modified to increase its storage or functional capacity [IEEE 90].|
|Fail safe||pertaining to a system or component that automatically places itself in a safe operating mode in the event of a failure [IEEE 90].|
|Fail soft||pertaining to a system or component that continues to provide partial operational capability in the event of certain failures [IEEE 90].|
|Fault||an incorrect step, process, or data definition in a computer program [IEEE 90].|
|Fault tolerance||the ability of a system or component to continue normal operation despite the presence of hardware or software faults [IEEE 90].|
|Fidelity||the degree of similarity between a model and the system properties being modeled [IEEE 90].|
|Flexibility||the ease with which a system or component can be modified for use in applications or environments other than those for which it was specifically designed [IEEE 90].|
|Functional scope||the range or scope to which a system component is capable of being applied.|
|Functional testing||testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions.|
Synonym : blackbox testing [IEEE 90].
|Generality||the degree to which a system or component performs a broad range of functions [IEEE 90].|
|Graphics||methods and techniques for converting data to or from graphic display via computers [McDaniel 94].|
|Hardware maintenance||the cost associated with the process of retaining a hardware system or component in, or restoring it to, a state in which it can perform its required functions.|
|Human Computer Interaction||a subfield within computer science concerned with the design, evaluation, and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them [Toronto 95].|
|Human engineering||the extent to which a software product fulfills its purpose without wasting user’s time and energy or degrading their morale [Boehm 78].|
|Implementation phase||the period of time in the software life cycle during which a software product is created from design documentation and debugged [IEEE 90].|
|Incompleteness||the degree to which all the parts of a software system or component are not present and each of its parts is not fully specified or developed.|
|Information Security||the concepts, techniques, technical measures, and administrative measures used to protect information assets from deliberate or inadvertent unauthorized acquisition, damage, disclosure, manipulation, modification, loss, or use [McDaniel 94].|
|Installation and checkout phase||the period of time in the software life cycle during which a software product is integrated into its operational environment and tested in this environment to ensure it performs as required [IEEE 90].|
|Integration testing||testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them [IEEE 90].|
|Integrity||the degree to which a system or component prevents unauthorized access to, or modification of, computer programs or data [IEEE 90].|
|Interfaces design||the activity concerned with the interfaces of the software system contained in the software requirements and software interface requirements documentation.|
Consolidates the interface descriptions into a single interface description of the software system [IEEE 91].
|Interface testing||testing conducted to evaluate whether systems or components pass data and control correctly to one another [IEEE 90].|
|Interoperability||the ability of two or more systems or components to exchange information and to use the information that has been exchanged [IEEE 90].|
|Latency||the length of time it takes to respond to an event [Barbacci 95].|
|Lifetime of operational capability||the total period of time in a system’s life that it is operational and meeting the user’s needs.|
|Maintainability||The ease with which a software system or component can be modified to correct faults, improve performance, or other attributes, or adapt to a changed environment [IEEE 90].|
|Maintenance control||the cost of planning and scheduling hardware preventive maintenance, and software maintenance and upgrades, managing the hardware and software baselines, and providing response for hardware corrective maintenance.|
|Maintenance measures||a category of quality measures that address how easily a system can be repaired or changed.|
|Maintenance personnel||the number of personnel needed to maintain all aspects of a computer system, including the support personnel and facilities needed to support that activity.|
|Manufacturing phase||the period of time in the software life cycle during which the basic version of a software product is adapted to a specified set of operational environments and is distributed to a customer base [IEEE 90].|
|Model||an approximation, representation, or idealization of selected aspects of the structure, behavior, operation, or other characteristics of a realworld process, concept, or system.|
Note : Models may have other models as components [IEEE 90].
|Modifiability||the degree to which a system or component facilitates the incorporation of changes, once the nature of the desired change has been determined [Boehm 78].|
|Necessity of characteristics||the degree to which all of the necessary features and capabilities are present in the software system Need satisfaction measures.|
A category of quality measures that address how well a system meets the user’s needs and requirements.
|Network management||the execution of the set of functions required for controlling, planning, allocating, deploying, coordinating, and monitoring the resources of a computer network [ITS 96].|
|Openness||the degree to which a system or component complies with standards.|
|Operability||the ease of operating the software [Deutsch 88].|
|Operational testing||testing conducted to evaluate a system or component in its operational environment [IEEE 90].|
|Operations and maintenance phase||the period of time in the software life cycle during which a software product is employed in its operational environment, monitored for satisfactory performance, and modified as necessary to correct problems or to respond to changing requirements [IEEE 90].|
|Operations personnel||the number of personnel needed to operate all aspects of a computer system, including the support personnel and facilities needed to support that activity.|
|Operations system||the cost of environmentals, communication, licenses, expendables, and documentation maintenance for an operational system.|
|Organizational measures||a category of quality measures that address how costly a system is to operate and maintain.|
|Parallel computing||a computer system in which interconnected processors perform concurrent or simultaneous execution of two or more processes [McDaniel 94].|
|Perfective maintenance||software maintenance performed to improve the performance, maintainability, or other attributes of a computer program [IEEE 90].|
|Performance measures||a category of quality measures that address how well a system functions.|
|Performance testing||testing conducted to evaluate the compliance of a system or component with specified performance requirements [IEEE 90].|
|Portability||The ease with which a system or component can be transferred from one hardware or software environment to another [IEEE 90].|
|Productivity||the quality or state of being productive [Webster 87].|
|Protocol||a set of conventions that govern the interaction of processes, devices, and other components within a system [IEEE 90].|
|Provably correct||the ability to mathematically verify the correctness of a system or component.|
|Qualification phase||the period of time in the software life cycle during which it is determined whether a system or component is suitable for operational use.|
|Qualification testing||testing conducted to determine whether a system or component is suitable for operational use [IEEE 90].|
|Quality measure||a software feature or characteristic used to assess the quality of a system or component.|
|Readability||the degree to which a system’s functions and those of its component statements can be easily discerned by reading the associated source code.|
|Realtime responsiveness||the ability of a system or component to respond to an inquiry or demand within a prescribed time frame.|
|Recovery||the restoration of a system, program, database, or other system resource to a prior state following a failure or externally caused disaster ; for example, the restoration of a database to a point at which processing can be resumed following a system failure [IEEE 90].|
|Reengineering||rebuilding a software system or component to suit some new purpose ; for example to work on a different platform, to switch to another language, to make it more maintainable.|
|Regression testing||selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified requirements [IEEE 90].|
|Reliability||the ability of a system or component to perform its required functions under stated conditions for a specified period of time [IEEE 90].|
|Requirements engineering||involves all lifecycle activities devoted to identification of user requirements, analysis of the requirements to derive additional requirements, documentation of the requirements as a specification, and validation of the documented requirements against user needs, as well as processes that support these activities [DoD 91].|
|Requirements growth||the rate at which the requirements change for an operational system.|
The rate can be positive or negative.
|Requirements phase||the period of time in the software life cycle during which the requirements for a software product are defined and documented [IEEE 90].|
|Requirements tracing||describing and following the life of a requirement in both forwards and backwards direction (i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases) [Gotel 95].|
|Resource utilization||the percentage of time a resource (CPU, Memory, I/O, Peripheral, Network) is busy [Barbacci 95].|
|Responsiveness||the degree to which a software system or component has incorporated the user’s requirements.|
|Restart||to cause a computer program to resume execution after a failure, using status and results recorded at a checkpoint [IEEE 90].|
|Retirement phase||the period of time in the software life cycle during which support for a software product is terminated [IEEE 90].|
|Reusability||the degree to which a software module or other work product can be used in more than one computing program or software system [IEEE 90].|
|Reverse engineering||the process of analyzing a system’s code, documentation, and behavior to identify its current components and their dependencies to extract and create system abstractions and design information.|
The subject system is not altered ; however, additional knowledge about the system is produced.
|Robustness||the degree to which a system or component can function correctly in the presence of invalid inputs or stressful environment conditions [IEEE 90].|
|Safety||a measure of the absence of unsafe software conditions.|
The absence of catastrophic consequences to the environment [Barbacci 95].
|Scalability||the ease with which a system or component can be modified to fit the problem area.|
|Security||the ability of a system to manage, protect, and distribute sensitive information.|
|Select or develop algorithms||the activity concerned with selecting or developing a procedural representation of the functions in the software requirements documentation for each software component and data structure.|
The algorithms shall completely satisfy the applicable functional and/or mathematical specifications [IEEE 91].
|Selfdescriptiveness||the degree to which a system or component contains enough information to explain its objectives and properties. [IEEE 90].|
|Simplicity||the degree to which a system or component has a design and implementation that is straightforward and easy to understand [IEEE 90].|
|Software architecture||the structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time [Clements 96].|
|Software change cycle time||the period of time that starts when a new system requirement is identified and ends when the requirement has been incorporated into the system and delivered for operational use|
|Software life cycle||the period of time that begins when a software product is conceived and ends when the software is no longer available for use.|
The life cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement phase.
These phases may overlap or be performed iteratively, depending on the software development approach used [IEEE 90].
|Software maintenance||the cost associated with modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment.|
|Software migration and evolution||see Adaptive maintenance.|
|Software upgrade and technology insertion||see Perfective maintenance.|
|Speed||the rate at which a software system or component performs its functions.|
|Statistical testing||employing statistical science to evaluate a system or component.|
Used to demonstrate a system’s fitness for use, to predict the reliability of a system in an operational environment, to efficiently allocate testing resources, to predict the amount of testing required after a system change, to qualify components for reuse, and to identify when enough testing has been accomplished [Poore 96].
|Structural testing||testing that takes into account the internal mechanism of a system or component.|
Types include branch testing, path testing, statement testing.
Synonym : white-box testing [IEEE 90].
|Structuredness||the degree to which a system or component possesses a definite pattern of organization of its interdependent parts [Boehm 78].|
|Sufficiency of characteristics||the degree to which the features and capabilities of a software system adequately meet the user’s needs.|
|Survivability||the degree to which essential functions are still available even though some part of the system is down [Deutsch 88].|
|System allocation||mapping the required functions to software and hardware.|
This activity is the bridge between concept exploration and the definition of software requirements [IEEE 91].
|System analysis and optimization||a systematic investigation of a real or planned system to determine the information requirements and processes of the system and how these relate to each other and to any other system, and to make improvements to the system where possible.|
|System security||a system function that restricts the use of objects to certain users [McDaniel 94].|
|System testing||testing conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements [IEEE 90].|
|Taxonomy||a scheme that partitions a body of knowledge and defines the relation-ships among the pieces.|
It is used for classifying and understanding the body of knowledge [IEEE 90].
|Test||an activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component [IEEE 90].|
|Test drivers||software modules used to invoke a module(s) under test and, often, provide test inputs, control and monitor execution, and report test results [IEEE 90].|
|Test phase||the period of time in the software life cycle during which the components of a software product are evaluated and integrated, and the software product is evaluated to determine whether or not requirements have been satisfied [IEEE 90].|
|Test tools||computer programs used in the testing of a system, a component of the system, or its documentation.|
Examples include monitor, test case generator, timing analyzer [IEEE 90].
|Testability||the degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met [IEEE 90].|
Note : Not only is testability a measurement for software, it can also apply to the testing scheme.
|Testing||the process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component [IEEE 90].|
|Throughput||the amount of work that can be performed by a computer system or component in a given period of time [IEEE 90].|
|Traceability||the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another [IEEE 90].|
|Training||Provisions to learn how to develop, maintain, or use the software system.|
|Trouble report analysis||the methodical investigation of a reported operational system deficiency to determine what, if any, corrective action needs to be taken.|
|Trustworthiness||the degree to which a system or component avoids compromising, corrupting, or delaying sensitive information.|
|Understandability||the degree to which the purpose of the system or component is clear to the evaluator [Boehm 78].|
|Unit testing||testing of individual hardware or software units or groups of related units [IEEE 90].|
|Usability||the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component [IEEE 90].|
|User interface||an interface that enables information to be passed between a human user and hardware or software components of a computer system [IEEE 90].|
|Verifiability||the relative effort to verify the specified software operation and performance [Evans 87].|
|Vulnerability||the degree to which a software system or component is open to unauthorized access, change, or disclosure of information and is susceptible to interference or disruption of system services.|
Répondre à cet article et accéder au Forum Glossaire des termes en informatique