abstraction
A description of something that omits some details that are not relevant to the purpose of the abstraction. It is the converse of refinement [D'Souza&Wills 1999]
Abstraction in programming is the process of identifying common patterns that have systematic variations; an abstraction represents the common pattern and provides a means for specifying which variation to use. [Gabriel 1996]
adaptability
Adaptability concerns the alteration of a system to fit the needs of a user without necessarily changing it from one machine to another. [NATO 1970]
adaptive maintenance
Modification of a software product performed after delivery to keep a computer program usable in a changed or changing environment [IEEE Std 1219-1998]
The hypothesis that remains tenable when the null hypothesis is rejected [ISERN]
The alternative hypothesis posits that there is no significant difference between two treatments (that is, between two methods, tools, techniques, environments or other conditions whose effects you are measuring) with respect to the dependent variable you are measuring (such as productivity, quality or cost) [Fenton&Pfleeger 1996].
See also: null hypothesis, statistical hypothesis.
analysis
The phase in the software life-cycle that emphasises on investigation of what the problem is rather than how a solution must be defined.
The organizational structure of a system or component [IEEE Std 610.12-1990]
The fundamental organisation of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE Std 1471-2000]
The architecture of a software system is the structural and behavioural framework on which all other aspects of the system depend. It is the organisational structure of a software system including components, connections, constraints, and rationale.
A family of architectures constrained bycomponent/connector vocabulary, topology, semantic constraints. (Source: Garland and Shaw tutorial)
architectural design
(1) 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.
(2) The result of the process in (1). [IEEE Std 610.12-1990]
That part of the design phase where the software architecture is defined.
architecture description
A collection of products to document an architecture. [IEEE Std 1471-2000]
artefact
The result of any activity in the software life-cycle such as requirements, architecture model, design specifications, source code and test scripts
A piece of information that is used or produced by a software development process. An artifact can be a model, a description, or software.
asset
A collection of artefacts.
benchmark
(1) A standard against which measurements or comparisons
can be made.
(2) A problem, procedure, or test that can be used to compare
systems or components to each other or to a standard as in (1).
(3) A
recovery file.
[IEEE Std 610.12-1990]
A benchmark is a set of tests used to compare the performance of alternative tools, methods, or techniques.
black-box reuse
A kind of reuse where a component is reused “as is” (i.e. without changing anything to the component). Paul Bassett argues that this is not a kind of reuse, but simply a use of the component!
business model
A model of real-world objects and their interactions -or rather, some users' understanding of them [D'Souza&Wills 1999]
business rule
A step or set of steps in a process or procedure or guide (algorithmic or heuristic) used by a customer for doing its business, work, or function, and often embodied in whole or in part in the software of a system [Chapin et al. 2001]
Capability Maturity Model (CMM)
Defined by the Software Engineering Institute (SEI) at Carnegie Mellon University. Describes the level of capability and maturity a software team could aim for and could be assessed against.
A case study is a research technique where you identify key factors that may affect the outcome of an activity and then document the activity: its inputs, constraints, resources, and outputs. Case studies usually look at a typical project, rather than trying to capture information about all possible cases; these can be thought of a "research in the typical". Formal experiments, case studies and surveys are three key components of empirical investigation in software engineering. [Fenton&Pfleeger 1996]
Occurs when making a change to one part of a software
system requires other system parts that depend on it to be changed as well.
These dependent system parts can on their turn require changes in other system
parts.
In this way, a single change to one system part may lead to a
propagation of changes to be made throughout the entire software system.
(French) A pattern describing salient features of a concept that supports recognition of that concept in some specified context by application of some specified comparison algorithm.
A collection of related features or characteristics that provide a shared technical vocabulary, including inter-feature relationships. (Source: Programmer's Apprentice, 1990)
client interface of a class
The set of all methods exported by the class (= public methods)
The client interface is used to access the functionality of objects. The interface is accessed by sending messages to objects, and the internal structure of the objects shouldn't be evident. [Lamping 1993]
See also: specialisation interface
The set of features or properties of a component (or system) that are the same, or common, between systems
compatibility
1. The ease of combining software elements with others [Meyer 1997]
2. The ability of two or more systems or components to perform their required functions while sharing the same hardware or software environment [IEEE Std 610.12-1990]
3. The ability of two or more systems or components to exchange information [IEEE Std 610.12-1990]
complexity
The degree to which a system or component has a design and implementation that is difficult to understand and verify [IEEE Std 610.12-1990]
That property of a language expression which makes it difficult to formulate its overall behaviour, even when given almost complete information about its atomic components and their inter-relations. [Edmonds 1997]
component
1. A component is a high-quality workproduct, designed, documented, and packaged to be reusable. A component is cohesive and has a stable interface [Jacobson et al. 1997]
2. A component is a physical and replaceable part of a system that conforms to and provides the realisation of a set of interfaces (Grady Booch)
compression
Compression is the characteristic of a piece of text that the meaning of any part of it is "larger" than that particular piece has by itself. This characteristic is created by a rich context, with each part of the text drawing on that context - each word draws part of its meaning from its surroundings. [Gabriel 1996]
Those interests which pertain to the system development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns can be logical or physiscal concepts, but they may also include system considerations such as performance, reliability, security, distribution, and evolvability. [IEEE Std 1471-2000]
confidence interval
A range of values that, considering all possible samples, has some designated probability of including the true population value [ISERN]
conformance
One behavioural description conforms to another if (and only if) any object hat behavs as described by one also behaves as described by the other (given a mapping between the two descriptions). A conformance is a relationship between the two descriptions, accompanied by a justification that includes the mapping between them and the rationale for the choices made. Refinement and conformance form the basis of traceability and document the answer to the "why" question: Why is this design done in this way? [D'Souza&Wills 1999]
consistency
The degree of uniformity, standardization, and freedom from contradiction among the documents or parts of a system or component. [IEEE Std 610.12-1990]
copy-and-modify reuse (or copy-and-edit reuse)
A widespread (but also very vicious) form of reuse where the reuser takes a copy of a component and starts modifying it without maintaining any form of consistency with the original component. In other words, there is no systematic way of keeping the two versions synchronised. The danger is of course a proliferation of versions, and an inability to upgrade to new versions of a component. This form of reuse only brings benefits on a very short-term basis.
corrective maintenance
Reactive modification of a software product performed after delivery to correct discovered faults [IEEE Std 1219-1998]
correctness
The ability of software products to perform their exact tasks, as defined by their specification [Meyer 1997]
Involves examining dependency relationships among software artefacts of the same kind, usually program entities (i.e. dependencies at the implementation level). This definition is more or less the same as the one of vertical traceability.
dependency graph
A graph in which the nodes represent software artefacts, and the edges represent all different kinds of dependency relationships between these artefacts
design
The phase in the software life-cycle that emphasises a logical solution, i.e. how the system fulfills the requirements. During object-oriented design, there is an emphasis on defining logical software objects that will ultimately be implemented in an object-oriented programming language. In this view, the design serves as a high level description of the source code, describing its key features and giving a blueprint of how the code is organised.
(1) The process of defining the architecture, components,
interfaces, and other characteristics of a system or component.
(2) The
result of the process in (1).
[IEEE Std 610.12-1990]
design recovery
A subset of reverse engineering in which domain knowledge, external information, and deduction or fuzzy reasoning are added to the observations of the subject system to identify meaningful higher-level abstractions beyond those obtained directly by examining the system itself. [Chikofsky&Cross 1990]
Design recovery recreates design abstractions from a combination of code, existing design documentation (if available), personal experience, and general knowledge about problem and application domains. Design recovery must reproduce all of the information required for a person to fully understand what a program does, how it does it, why it does it, and so forth. Thus, it deals with a far wider range of information than found in conventional software engineering representations or code. [Biggerstaff 1989]
detailed design
(1) 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.
(2) The result of the process in (1).
[IEEE Std 610.12-1990]
disciplined reuse
A form of reuse where a degree of consistency is maintained between the original component and its reusers. With disciplined reuse the benefits of reuse are much more sustainable.
domain
A problem area. Typically, many application programs exist to solve the problems in a single domain. The following prerequisites indicate the presence of a domain: the existence of comprehensive relationships among objects in the domain, a community interested in solutions to the problems in the domain, a recognition that software solutions are appropriate to the problems in the domain, and a store of knowledge or collected wisdom to address the problems in the domain. Once recognized, a domain can be characterized by its vocabulary, common assumptions, architectural approach, and literature. [Arango Prieto-Diaz 1991]
An area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area [Prieto-Diaz 1990]
The part of domain engineering that deals with identifying commonalities, similarities and variabilities of an application or an application domain [Jacobson et al. 1997].
A systematic way of defining, implementing and evolving a domain in terms of commonalities and variabilities
Domain scoping identifies the domains of interest, the stakeholders, and their goals, and defines the scope of the domain. [Arrango 1994]
Domain modeling is the activity for representing the domain, or the domain model. Typically a domain model is formed through a commonality and variability analysis to concepts in the domain. [Arrango 1994]
ease of use
The ease with which people of various backgrounds and qualifications can learn to use software products and apply them to solve problems. It also covers the ease of installation, operation and monitoring.
economy
Economy, seen as a software quality, is the ability of a system to be completed on or below its assigned budget [Meyer 1997]
efficiency
The ability of a software system to place as few demands as possible on hardware resources, such as processor time, space occupied in internal and external memories, bandwidth used in communication devices [Meyer 1997]
The degree to which a system or component performs its designated functions with minimum consumption of resources. In case of time resources we speak of execution efficiency. In case of available storage resources we speak of storage efficiency [IEEE Std 610.12-1990]
effort estimation
The process to estimate in advance the effort (or time) required to make a certain software change
emergency maintenance
Unscheduled corrective maintenance performed to keep a system operational [IEEE Std 1219-1998]
The profession in which a knowledge of the mathematical and natural sciences gained by study, experience and practice is applied with judgement to develop ways to utilize, economically, the materials and forces of nature for the benefit of mankind [Accreditation Board for Engineering and Technology, 1996]
See also software engineering
See software entropy
evolutionary software development
This is basically the same as iterative incremental software development, but the term stresses the fact that a software system is never completely finished, and that it continues to evolve after it has been delivered.
evolvability
The capability of software products to be evolved to continue to serve its customer in a cost effective way [Cook&al2000]
In general, an experiment is defined as an act or operation for the purpose of discovering something unknown or testing a principle, supposition, etc. In software engineering: a trial that is conducted in order to verify a hypothesis defined beforehand in a controlled setting in which the most critical factors can be controlled or monitored [ISERN]
A formal experiment is a rigorous, controlled investigation of an activity, where key factors are identified and manipulated to document their effects on the outcome. By their nature, since formal experiments require a great deal of control, they tend to be small, involving small numbers of people or events. We can think of experiments as "research in the small". Formal experiments, case studies and surveys are three key components of empirical investigation in software engineering. [Fenton&Pfleeger 1996]
experimental error
Measure that includes all uncontrolled sources of variation affecting a particular score [ISERN]
The ease with which a system or component can be modified to increase its storage or functional capacity [IEEE Std 610.12-1990]
The ease of adapting software products to changes of specification [Meyer1997].
extensibility
See extendability
fact
Information considered to be objectively real because it was obtained through observation [ISERN]
A feature describes prominent or distinctive user-visible aspects, quality or characteristics of a software system or systems [Kang et al. 1990]
A feature is an observable and relatively closed behaviour or characteristic of a (software) part [Pulvermuller&al2001].
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 Std 610.12-1990]
formal experiment
See experiment.
formal method
A formal method of software development is a process for developing software that exploits the power of mathematical notation and mathematical proofs [Wordsworth 1999]
The traditional process of moving from high-level abstractions and logical, implementation-independent designs to the physical implementation of a system
Forward engineering is the traditional process of moving from high-level abstractions and logical, implementation-independent designs to the physical implementation of a system. Forward engineering follows a sequence of going from requirements through designing its implementation. [Chikofsky&Cross 1990]
fragile base class problem
Refers to the problem that occurs when independently developed subclasses are broken when their base class evolves.
framework
A framework is a reusable design of all or part of a software system described by a set of abstract classes and the way instances of those classes collaborate[Roberts&Johnson 1996].
A framework is a micro-architecture that provides an extensible template for applications within a specific domain [OMG 1997].
functional design
(1) The process of defining the working relationships among
the components of a system.
(2) The result of the process in (1). [IEEE Std 610.12-1990]
functionality
The extent of possibilities provided by a system [Meyer 1997]
generality
The degree to which a system or component performs a broad range of functions [IEEE Std 610.12-1990]
habitability
The characteristic of source code that enables programmers, coders, bug-fixers and people coming to the code later in its life to understand its construction and intentions, and to change it comfortably and confidently. [Gabriel 1996]
See also: maintainability
heuristic
(1) Involving or serving as an aid to learning, discovery or problem solving by experimental and especially trial-and-error methods
(2) Of or relating to exploratory problem-solving techniques that utilize self-educating techniques (as the evaluation of methods) to improve performance (e.g., a heuristic computer program)
horizontal reuse
Horizontal reuse provides generic reusable components that can support a variety of products. In other words, the components can be reused in different domains or product families.
Expresses relationships between software artefacts that reside in different phases of the software life-cycle, e.g. dependencies between a requirements specification and a design component
See also: vertical traceability
A tentative explanation that accounts for a set of facts and can be tested by further investigation; a theory [ISERN]
The hypothesis is the tentative theory of supposition that you think explains the behaviour you want to explore. Wherever possible, you should try to state your hypothesis in quantifiable terms, so that it is easy to tell whether the hypothesis is confirmed or refuted [Fenton&Pfleeger 1996].
See also: research hypothesis, statistical hypothesis.
impact analysis
Impact analysis tries to assess the impact of changes on the rest of the system: when a certain component changes, which system parts will be affected, and how will they be affected?
See also: change propagation
implementation
The phase in the software life-cycle where the actual software is implemented. The result of this phase consists of source code, together with documentation to make the code more readable.
A state in which two or more overlapping elements of different software models make assertions about aspects of the system they describe which are not jointly satisfiable [Spanoudakis&Zisman 2001].
inconsistency management
The process by which inconsistencies between software models are handled so as to support the goals of the stakeholders concerned [Finkelstein&al 1996].
integrity
The ability of software systems to protect their various components (programs, data) against unauthorized access and modification [Meyer 1997]
Intercession is the ability of a program to modify its own execution state or to alter its own interpretation or meaning [Maes 1987].
See also reflection
Introspection is the ability of a program to observe and therefore reason about its own state [Maes 1987].
See also reflection
invocation latency
The time from application invocation to when execution of the program actually begins [KrintzEtAl1998].
iterative incremental software development
The process of developing a software system in small steps (increments) by iterating a number of times over the different software phases.
law
A statement that predicts behavior under certain defined conditions, that is based on facts, reason, and observation, and that is accepted as true. There are no established laws in software engineering [ISERN]
level of significance
Probability of rejecting the null hypothesis when it is true [ISERN]
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 Std 610.12-1990]
A measure provides a quantitative indication of the extent, amount, dimensions, capacity or size of some attribute of a product or process. [IEEE Std 729-1993]
measurement
The process by which numbers or symbols are assigned to attributes of entities in the real world in such a way as to describe them according to clearly defined rules [Fenton&Pfleeger 1996]
The experimental process in which, to precisely describe the entities or events in real world, numbers or other symbols are assigned to its attributes by using a given scale. The result of the measurement is called a measure. [Abreu&al 2000]
The act of determining a measure. [IEEE Std 729-1993]
A quantitative measure of the degree to which a system, component or process possesses a given attribute. [IEEE Std 729-1993]
See also software metric
mixin
A mixin is a subclass definition that may be applied to different superclasses to create a related family of modified classes [Bracha&Cook 1990, page 303]
A mixin is a free-standing class extension function that abstracts over its own superclass [Simons 1995]
model
A model is a simplified representation of a system or phenomenon with any hypotheses required to describe the system or explain the phenomenon, often mathematically. It is an abstraction of reality emphasizing those aspects that are of interest to someone [ISERN]
modify-and-retrofit reuse
The opposite of copy-and-modify reuse. Instead of copying a component and making changes to the copy, the original component is modified directly. Since this has an impact on all the other components that make use of it, we might need to make modifications to these components as well. This often leads to a propagation of changes throughout the entire software system.
null hypothesis (H0)
A statement concerning one or more parameters that is subjected to statistical test [ISERN].
The hypothesis that there is no significant difference between two treatments (that is, between two methods, tools, techniques, environments, or other conditions whose effects you are measuring (such as productivity, quality, or cost). The null hypothesis is assumed to be true unless the data indicates otherwise [Fenton&Pfleeger 1996].
See also: alternative hypothesis, statistical hypothesis.
object-oriented design
A software development technique in which a system or component is expressed in terms of objects and connections between those objects [IEEE Std 610.12-1990]
object-oriented language
A programming language that allows the user to express a program in terms of objects and messages between those objects [IEEE Std 610.12-1990]
observation
A discrete instance of the phenomena being studied, e.g. a specific software module, a specific code review, an individual programmer [ISERN]
paradigm
A point of view in which some principles, approaches, concepts, and even theories, have been stated uniformly. A set of assumptions about reality that, when applied to a particular situation, can be used as a guide for action. For example, the Quality Improvement Paradigm. [ISERN]
A philosophical and theoretical framework of a scientific school or discipline within which theories, laws, and generalizations and the experiments performed in support of them are formulated. [Merriam-Webster's dictionary, 2002]
pattern
A standard (object-oriented) design for addressing frequently occuring problems, described in a standard way [Gamma et al. 1994]
perfective maintenance
Modification of a software product after delivery to improve performance or maintainability [IEEE Std 1219-1998]
piecemeal growth
The process of design and implementation in which software is embellished, modified, reduced, enlarged, and improved through a process of repair rather than replacement. [Gabriel 1996]
A set of subsystems and technologies that provide a coherent set of functionality through interfaces and specified usage patterns, which any application supported by that platform can use without concern for the details of how the functionality provided by the platform is implemented [Kleppe et al. 2003]
platform model
Provides a set of technical concepts, representing the different kinds of parts that make up a platform and the services provided by that platform. [Kleppe et al. 2003]
population
All observations of the phenomena being studied, e.g. all software modules, all code reviews, all programmers [ISERN]
portability
The ease of transferring software products to various hardware and software environments [Meyer 1997]
Portability is the property of a system which permits it to be mapped from one environment to a different environment[NATO 1970]
power of test
Probability of rejecting the null hypothesis when the alternative hypothesis is true [ISERN]
preliminary design
(1) The process of analyzing design alternatives and
defining the architecture, components, interfaces, and timing and sizing
estimates for a system or component.
(2) The result of the process in
(1).
[IEEE Std 610.12-1990]
See product line
A collection of existing and potential products that address a coherent business area and share a set of similar characteristics. All these products are made by the same process and for the same purpose, and differ only in style, model or size.
product-line based reuse
A kind of reuse that exploits the commonalities in a product line (or product family) and established the bounds of variability among the products, making it possible to develop common assets and streamlining the development process.
realisation
See refinement [D'Souza&Wills 1999]
Redocumentation is the creation or revision of a semantically equivalent representation within the same relative abstraction level. The resulting forms of representation are usually considered alternative views (for example, dataflow, data structure, and control flow) intended for human audience. Redocumentation is the simplest and oldest form of reverse engineering, and many consider it to be an unintrusive, weak form of restructuring. The "re-" prefix implies that the intent is to recover documentation about the subject system that existed or should have existed. [Chikofsky&Cross 1990]
Reengineering, also known as both renovation and reclamation, is the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form. Reengineering generally includes some form of reverse engineering (to achieve a more abstract description) followed by some form of forward engineering or restructuring. This may include modifications with respect to new requirements not met by the original system. [Chikofsky&Cross 1990]
[noun]A change made to the internal structure of
software to make it easier to understand and cheaper to modify without changing
its observable behaviour.
[verb]To restructure software by applying a
series of refactorings without changing its observable behaviour. [Fowler
1999]
See also: restructuring
A refinement is a detailed description that conforms to another (its abstraction). Everything said about the abstraction holds, perhaps in a somewhat different form, in the refinement [D'Souza&Wills 1999]
Reflection is the ability of a program to manipulate as data, something representing the state of the program during its own execution. There are two aspects of such manipulation: introspection and intercession. Both aspects require a mechanism for encoding execution state as data; providing such an encoding is called reification [Maes 1987].
See reflection
Software reliability is the probability of a failure-free operation of a computer program in a specified environment for a specified time [Musa et al. 1987].
repairability
Repairability is the ability to facilitate the repair of defects [Meyer 1997].
replication
The collection of two or more observations under a set of identical experimental conditions [ISERN]
Repetition of the basic experiment under identical experiments, rather than repeating measurements on the same experimental unit [Fenton&Pfleeger 1996].
a statement about what the proposed system will do that all stakeholders agree must be made true in order for the customer's problem to be adequately solved [LehtbridgeLaganiere2001]
requirements phase
The phase in the software life-cycle where is defined what the system should do, i.e., what are the (functional and non-functional) requirements?
A software requirements specification is traceable if (1) the origin of each of its requirements is clear and if (2) it facilitates the referencing of each requirement in future development or enhancement documentation [IEEE 1993]
A tentative theory or supposition provisionally adopted to account for certain facts and to guide in the investigation of others [ISERN]
Restructuring is the transformation from one representation form to another at the same relative abstraction level, while preserving the subject system's external behaviour (functionality and semantics). A restructuring transformation is often one of appearance, such as altering code to improve its structure in the traditional sense of structured design. While restructuring creates new versions that implement or propose change to the subject system, it does not normally involve modifications because of new requirements. However, it may lead to better observations of the subject system that suggest changes that would improve aspects of the system. Restructuring is often used as a form of preventive maintenance to improve the physical state of the subject system with respect to some preferred standard. It may also involve adjusting the subject system to meet new environmental constraints that do not involve reassessment at higher abstraction levels. [Chikofsky&Cross 1990]
reusability
The ability of software elements to serve for the construction of many different applications [Meyer 1997]
The degree to which a software module or other work product can be used in more than one computer program or software system [IEEE Std 610.12-1990]
reusable asset
A reusable asset is a tangible resource that is acquired or developed for the solution of multiple problems, such as specifications, designs, code, test cases, etc.
reuse
The process of adapting generalised components to various contexts of use [Bassett 1997]
Repeated use of an artifact, typically outside the original context in which the artifact was created [Jacobson et al. 1997]
reuse capability
The range of expected results in reuse effectiveness, proficiency, and efficiency that an organisation is able to achieve through its process.
The process of developing a set of specifications for a complex hardware system by an orderly examination of specimens of that system.[Rekoff 1985]
The process of analysing an existing system to identify its components and their interrelationships and create representations of the system in another form or at a higher level of abstraction. Reverse engineering is usually undertaken in order to redesign the system for better maintainability or to produce a copy of a system without access to the design from which it was originally produced. For example, one might take the executable code of a computer program, run it to study how it behaved with different input and then attempt to write a program oneself which behaved identially (or better). An integrated circuit might also be reverse engineered by an unscrupulous company wishing to make unlicensed copies of a popular chip. (1995-10-06)
The process of extracting software system information (including documentation) from source code [IEEE Std 1219-1998]
Reverse engineering is the process of analyzing a subject system to: identify the system's components and their interrelationships and; create representations of the system in another form or at a higher level of abstraction. Reverse engineering generally involves extracting design artifacts and building or synthesizing abstractions that are less implementation-dependent. Reverse engineering in and of itself does not involve changing the subject system or creating a new system based on the reverse-engineered subject system. It is a process of examination, not a process of change or replication. [Chikofsky&Cross 1990]
ripple effect
The phenomenon where a change in one piece of a software system affects at least one other area of the same software system (either directly or indirectly)
See also: change propagation
robustness
The ability of software systems to react appropriately to abnormal conditions [Meyer 1997]
round-trip engineering
The seamless integration between design and source code, between modeling and implementation. With round-trip engineering a programmer generates code from a design, changes that code in a separate development environment, and recreates the adapted design diagram back from the source code[Demeyer&al 1999]
An iteration between modelling, generating code, changing that code and mapping this code back to the original model [Demeyer&al 2000]
sample
A subset of a population [ISERN]
simplicity
The degree to which a system or component has a design and implementation that is straightforward and easy to understand [IEEE Std 610.12-1990]
software
Software is part of a system solution that can be encoded to execute on a computer as a set of instructions; it includes all the associated documentation necessary to understand, transform and use that solution [ISERN]
Software is the collection of computer programs, procedures, rules, and associated documentation and data [IEEE]
Software is the non-hardware part, including associated documentation, of a system being implemented or implemented in part with a computer or an embedded processor [Rosen 1992]
software aging
Relates to the problem that the quality of software decreases, and the software entropy increases, as the software evolves over time.
software change
software configuration management (SCM)
The discipline of managing and controlling change in the evolution of software systems. (IEEE Standard 1042, 1987)
The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. [NATO1969]
The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. [IEEE Std 610.12-1990]
The systematic activities involved in the design, implementation and testing of software to optimize its production and support. [Canadian Standards Association]
The amount of disorder in a software system
The life of the software after its initial development cycle (or after the first delivery of the software system). Any subsequent change to the software, such as bug fixes and adding new functionality, is considered to be software evolution.
All programming activity that is intended to generate a new software version from an earlier operational version [Lehman&Ramil2000]
The application of software maintenance activities and processes that generate a new operational software version with a changed customer-experienced functionality or properties from a prior operational version (…) together with the associated quality assurance activities and processes, and with the management of the activities and processes [Chapin et al. 2001]
See also: software maintenance
The process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment. [IEEE Std 610.12-1990]
Modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment [IEEE Std 1219-1998]
The software product undergoes modification to code and associated documentation due to a problem or the need for improvement. The objective is to modify the existing software while preserving its integrity [ISO Std 12207-1995]
The deliberate application of activities and processes, whether or not completed, to existing software that modify either the way the software directs hardware of the system, or the way the system (of which the software is a part) contributes to the business of the system’s stakeholders, together with the associated quality assurance activities and processes, and with the management of the activities and processes, and often done in the context of software evolution [Chapin et al. 2001]
See also: software evolution
A software metric is a combination from measures of attributes belonging to a software product, or to its development process, which shows quantitatively some of its characteristics. [Abreu&al 2000]
The phases a software product goes through between when it
is conceived and when it is no longer available for use.
The software
life-cycle typically includes the following: requirements analysis, design,
construction, testing (validation), installation, operation, maintenance, and
retirement.
The development process tends to run iteratively through these
phases rather than linearly; several models (spiral, waterfall, etc.) have been
proposed to describe this process.
Other processes associated with a software
product are: quality assurance, marketing, sales and
support.
(1996-12-27)
specialisation interface of a class
The specialization interface is used to extend and modify classes. It is accessed by making a subclass and adding messages and methods, refining types, or overriding methods. The last of these, overriding methods, is the operation that can modify behaviour and than can interact with the internal structure of the class. [Lamping 1993]
See also: client interface
statistic
A descriptive measure of a sample, e.g., mean [ISERN]
A statement about one or more parameters of a population. The null hypothesis and alternative hypothesis are two forms of a statistical hypothesis [ISERN]
A mathematical statement concerning the sampling distribution of a random variable that is used in evaluating the outcome of an experiment or in predicting the outcome of future replications of an experiment [ISERN].
A statistic whose purpose is to provide a test of some statistical hypothesis. Test statistics such as t and F have known sampling distributions that can be employed in determining the probability of an obtained result under the null hypothesis [ISERN].
structured design
(1) Any disciplined approach to software design that
adheres to specified rules based on principles such as modularity, top-down
design, and stepwise refinement of data, system structures, and processing
steps.
(2) The result of applying the approach in (1). [IEEE Std 610.12-1990]
A survey is a retrospective study of a situation to try to document relationships and outcomes. A survey is always done after an event has occurred. When performing a suvey, you have no control over the situation at hand. That is, because it is a retrospective study, you can record a situation and compare it with similar ones. But you cannot manipulate variables as you do with case studies and experiments. Surveys try to poll what is happening broadly over large groups of projects: "research in the large" [Fenton&Pfleeger 1996].
systematic reuse
Reuse is not restricted to certain phases of the software life-cycle, and even not to single applications. The idea of systematic reuse is that reuse takes place continuously during the entire software development process. Consequently, systematic software reuse corresponds to the purposeful creation, management and application of reusable assets.
testing
The phase in the software life-cycle that aims at uncovering defects by executing specialised test programs and test cases.
The activity of uncovering defects in an implementation by comparing its behaviour against that of its specification under a given set of runtime stimuli (the test cases or test data). [D'Souza&Wills 1999]
timeliness
The ability of a software system to be released when or before its users want it [Meyer 1997]
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; for example, the degree to which the requirements and design of a given software component match. [IEEE Std 610.12-1990]
The degree to which each element in a software development product establishes its reason for existing; for example, the degree to which each element in a bubble chart references the requirement that it satisfies [IEEE Std 610.12-1990]
See also: requirements traceability
traceability analysis
The same as dependency analysis, but it usually involves examining dependency relationships between software artefacts at different phases of the software life-cycle, e.g. a dependency between a requirements specification and a corresponding design component.
The automatic generation of a target model from a source model, according to a transformation definition. [Kleppe et al. 1990]
a set of transformation rules that together describe how a model in the source language can be transformed into a model in the target language. [Kleppe et al. 1990]
a description of how one or more constructs in the source language can be transformed into one or more constructs in the target language. [Kleppe et al. 1990]
Usability of a software product is the extent to which the product is convenient and practical to use [Boehm et al 1978].
The set of features or properties of a component (or system) that vary, or differ, between systems.
verifiability
The ease of preparing acceptance procedures, especially test data, and procedures for detecting failures and tracing them to errors during the validation and operation phases [Meyer 1997]
vertical reuse
Vertical reuse is the process of developing components that can only be reused in a given product family.
Expresses relationships between software artefacts in the same phase of the software life-cycle. In this sense, it is the same as dependency analysis, but not necessarily restricted to the implementation phase.
See also: horizontal traceability
A view is a representation of a whole system from the perspective of a related set of concerns. [IEEE Std 1471-2000]
A viewpoint is a specification of the conventions for constructing and using a view. [IEEE Std 1471-2000]
[Abreu&al2000] Fernando Brito e Abreu: ???, 2000.
[Arrango 1994] G. Arrango. Domain Analysis Methods. In Software Reusability, pp. 17-49, Ellis-Horwood, New York, 1994.
[Bassett 1997] Paul G. Bassett: Framing Software Reuse: Lessons From the Real World. Yourdon Press Computing Series, ISBN 0-13-327859-X, Prentice Hall, 1997.
[Biggerstaff 1989] T. J. Biggerstaff: Design Recovery for Maintenance and Reuse. IEEE Computer, July 1989, pp. 36-49.
[Boehm et al 1978] B.W. Boehm and J. R. Brown and J.R. Kaspar et al. Characteristics of software quality. TRW Series of Software Technology, Amsterdam, North Holland, 1978.
[Booch et al. 1990] G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 1999.
[Bracha&Cook 1990] Gilad Bracha, William Cook: Mixin-based inheritance. Proc. ECOOP/OOPSLA, 1990.
[Chapin et al. 2001] N. Chapin, J.E. Hale, K.Md. Khan, J.F. Ramil, W.-G. Tan. Types of software evolution and software maintenance. Journal of Software Maintenance and Evolution: Research and Practice, 13: 3-30, 2001.
[Chikofsky&Cross 1990] E.J. Chikofsky, J.H. Cross II. Reverse Engineering and Design Recovery: A Taxonomy. IEEE Software Engineering Journal, pp. 13-17, Jan. 1990.
[Cook et al. 2000] S. Cook, He Ji, Rachel Harrison. Software Evolution and Software Evolvability. Technical Report, University of Reading, 2000.
[Demeyer et al. 1999] S. Demeyer, S. Ducasse, S. Tichelaar. Why unified is not universal. UML shortcomings for coping with round-trip engineering. Proc. Int. Conf. UML, Springer-Verlag, 1999.
[Demeyer et al. 2000] S. Demeyer, S. Ducasse, O. Nierstrasz. Finding Refactorings via Change Metrics. Proc. Int. Conf. OOPSLA 2000, ACM Press, October 2000.
[D'Souza&Wills 1999] Desmond F. D'Souza, Alan Cameron Wills. Objects, Components and Frameworks with UML: The Catalysis Approach. ISBN 0-201-31012-0, Addison-Wesley, 1999.
[Edmonds 1997] B. Edmonds. Complexity and scientific modelling. Proc. 20th Int'l Wittgenstein Symposium, Austria, August 1997.
[Fenton&Pfleeger 1996] Norman E. Fenton, Shari Lawrence Pfleeger. Software Metrics: A Rigorous and Practical Approach. Thomson Computer Press, 1996.
[Finkelstein&al 1996] A. Finkelstein, G. Spanoudakis, D. till. Managing interference. Joint Proceedings Sigsoft '96, pp. 172-174, ACM Press, 1996.
[Fowler 1999] Martin Fowler. Refactoring: improving the design of existing programs. Addison-Wesley, 1999.
[Gabriel 1996] Richard P. Gabriel. Patterns of Software: Tales from the Software Community. ISBN 0-19-512123-6, Oxford University Press, 1996.
[Gamma&al 1994] Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994.
[IEEE Std 729-1993] IEEE Software Engineering Standard 729-1993: Glossary of Software Engineering Terminology. IEEE Computer Society Press, 1993.
[IEEE Std 610.12-1990] IEEE Standard Glossary of Software Engineering Terminology 610.12-1990. In IEEE Standards Software Engineering, 1999 Edition, Volume One: Customer and Terminology Standards. IEEE Press, 1999.
[IEEE Std 1219-1998] IEEE Standard for Software Maintenance, IEEE Std 1219-1998. In IEEE Standards Software Engineering, 1999 Edition, Volume Two: Process Standards. IEEE Press, 1999.
[IEEE Std 1471-2000] IEEE Standards Board. Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Std 1471-2000. September 2000.
[ISERN] International Software Engineering Research Network, http://www.iese.fhg.de/ISERN/
[ISO Std 12207-1995] International Standards Organisation. ISO 12207 Information Technology: Software Life Cycle Processes, Geneva, Switzerland, 1995.
[Jacobson&al 1997] Ivar Jacobson, Martin Griss and Patrik Jonsson: Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley, 1997.
[Kang et al. 1990] K. Kang, S. Cohen, J. Hess, W. Novak, S. Peterson. Feature-oriented domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-021, 1990.
[Kleppe et al. 1990] Kleppe, J. Warmer, W. Bast. MDA Explained, The Model-Driven Architecture: Practice and Promise, Addison Wesley, 2003.
[Krintz et al. 1998] Chandra Krintz, Brad Calder, Han Bok Lee, Benjamin G. Zorn. Overlapping Execution with Transfer Using Non-Strict Execution for Mobile Programs. Proc. Int. Conf. Architectural Support for Programming Languages and Operating Systems, ACM Press, 1998.
[Lamping 1993] John Lamping. Typing the specialization interface. Proc. OOPSLA'93, ACM SIGPLAN Notices 28(10), pp. 201-214, October 1993, ACM Press.
[Maes 1987] Pattie Maes. Computational Reflection. PhD Thesis, Artificial Intelligence Laboratory, Vrije Universiteit Brussel, 1987.
[Meyer 1997] Bertrand Meyer. Object-Oriented Software Construction, second edition. Prentice-Hall, 1997.
[Musa et al. 1987] J. D. Musa, A. Iannino, K. Okumoto. Engineering and Managing Software with Reliability Measures, McGraw-Hill, 1987.
[NATO 1969] P. Naur, B. Randall (Eds.). Software Engineering: A Report on a Conference Sponsored by the NATO Science Committee, NATO, 1969.
[NATO 1970] B. Randall, J. N. Buxton. Software Engineering Techniques: A Report on a Conference Sponsored by the NATO Science Committee, NATO 1970.
[OMG 1997Sem] Object Management Group: UML Semantics. OMG Document ad/97-08-04, Version 1.1, 1 September 1997.
[Prieto-Diaz 1990] R. Prieto-Diaz: Domain Analysis: an Introduction. ACM SIGSOFT Software Engineering Notes, 15(2), ACM Press, 1990.
[Pulvermuller&al2001] E. Pulvermuller, A. Speck, J. O. Coplien, M. D'Hondt, W. De Meuter. Feature Interaction in Composed Systems, 2001.
[Rekoff 1985] M.G. Rekoff Jr.: On Reverse Engineering. IEEE Trans. Systems, Man, and Cybernetics, March-April 1985, pp. 244-252.
[Roberts&Johnson 1996] Don Roberts and Ralph Johnson: Evolving Frameworks: A Pattern-language for Developing Object-oriented Frameworks. PLoP '96 Proceedings, 1996.
[Rosen 1992] S. Rosen: Encyclopedia of Computer Science. Van Nostrand Reinhold, 1992.
[Simons1995] A.J.H. Simons: Mixins: Typing the Superclass Interface. Technical Report, 1995.
[Spanoudakis&Zisman 2001] G. Spanoudakis, A. Zisman: Inconsistency management in software engineering: Survey and open research issues. In Handbook of Software Engineering and Knowledge Engineering, 1, pp. 329-380, World Scientific Publishing Co., 2001.
[Wordsworth 1999] J. B. Wordsworth: Getting the best from formal methods. Information and Software Technology 41(14), November 1999, pp. 1027-1032.