law of continuing change [N-COUNT-U14] The law of continuing change is a principle that states that a system in use should undergo continuing change until it becomes more cost effective to restructure the system.
law of increasing complexity [N-COUNT-U14] The law of increasing complexity is a principle that states that a structure becomes more complex with every change that is made to it.
layered [ADJ-U6] If an architectural style is layered, it is organized by ascending functionality.
legacy system [N-COUNT-U15] A legacy system is an old software system that continues to be updated and used. logical [ADJ-U1] If something is logical, it is based on evidence and reason.
main program with subroutines [N-COUNT-U6] A main program with subroutines is a hierarchical system in which a top level module invokes other modules in a given order.
market-driven [ADJ-U4] If software is market-driven, it is developed for a broad purpose rather than a specific need. mode [N-COUNT-U4] A mode is a changeable system of operation that dictates how software behaves.
modeling stage [N-COUNT-U9] The modeling stage is a stage in JSD in which a description is made of the problem that the software needs to solve.
modernize [V-T-U15] To modernize something is to make it compatible with new technology or update its appearance and functionality.
modularity [N-UNCOUNT-U7] Modularity is a way of viewing a system as a series of smaller interconnected systems, module [N-COUNT-U5] A module is a group of software functions that are bundled together.
monotonicity property [N-COUNT-U13] The monotonicity property is a property of test adequacy criteria that states that additional testing can be performed even after a program has been adequately tested.
Glossary
network stage [N-COUNT-U9] The network stage is a stage in JSD in which a system is shown as a network of communicating processes.
non-exhausting applicability property [N-COUNT-U13] The non-exhausting applicability property is a property of test adequacy criteria that states that a criterion does not require exhaustive testing in all circumstances.
object [N-COUNT-U4] An object is a physical thing that can be touched and seen.
object-oriented [ADJ-U10] If a design is object-oriented, it uses objects, or data structures, as a basis for designing software.
OMT [N-UNCOUNT-UIO] The OMT (Object Modeling Technique) is an object-oriented approach to software development. open system [N-COUNT-U3] An open system is a system that allows mass to enter and leave it.
oracle [N-COUNT-U11] An oracle is a mechanism used to compare predicted results with the actual results of a software test.
output [N-COUNT-U3] An output is the amount of an extensive quantity that is removed from a system, but not destroyed, during a particular period of time.
outside the box [ADV PHRASE-U1] If someone thinks outside the box, he or she has ideas that are creative or unusual for a particular situation.
peer review [N-UNCOUNT-U12] Peer review is a practice in which engineers read the programs of other engineers to identify faults or inadequacies in programs.
perfective maintenance [N-UNCOUNT-U14] Perfective maintenance is the practice of updating software in order to accommodate new user requirements.
philosophy [N-COUNT-U8] A philosophy is a way of understanding or viewing something.
pipes and filters [N-UNCOUNT-U6] Pipes and filters is a style that relies on input streams and system operations to process ordered data.
prevention model [N-COUNT-U11] The prevention model is a type of software testing intended to prevent faults in design, requirements, and implementation.
preventive maintenance [N-UNCOUNT-U14] Preventive maintenance is the practice of improving the structure of a system in order to make it easier to maintain.
primitive [ADJ-U8] If something is primitive, it is simple or basic.
problem identification [N-UNCOUNT-U2] Problem identification is the act of describing and analyzing problems at the first stage of the problem solving process.
problem solving [N-UNCOUNT-U2] Problem solving is the ability to identify problems, think of solutions, and enact those solutions.
procedure [N-UNCOUNT-U2] A procedure is an established series of actions that dictates how to do something. process view [N-COUNT-U5] A process view is a way to describe a software system in terms of the tasks and
processes a system performs and the way those tasks and processes interact.
programming plan [N-COUNT-U5] A programming plan is a program fragment that is used to describe a common action.
proof of correctness [N-UNCOUNT-U12] Proof o f correctness is a process which formally states a program’s specification and proves that the program meets that specification.
property [N-COUNT-UIO] A property is an identifying and descriptive characteristic or attribute, and may apply to a single entity or a relationship between entities.
rational [ADJ-U8] If a design process is rational, it works according to a logical system. redefine [V-T-U2] To redefine something is to change its function or meaning.
redocumentation [N-COUNT-U15] Redocumentation is the process of improving or simplifying a program’s code without changing its function or level of abstraction.
reengineering [N-UNCOUNT-U15] Reengineering, also called renovation, is the process of making functional changes to a system.
relationship [N-COUNT-UIO] A relationship is a property that depends on the way two entities interact. release [N-COUNT-U14] A release is an updated version of an existing software program.
renaming property [N-COUNT-U13] The renaming property is a property of test adequacy that states that two programs that differ only in unimportant ways can be tested with the same test sets.
renovation [N-UNCOUNT-U15] Renovation, also called reengineering, is the process of making functional changes to a system.
repair [V-T-U14] To repair something is to fix parts of it that are not functioning correctly.
repository [N-COUNT-U6] A repository is an architectural style designed for systems which manage a body of data with an inherent structure.
requirements engineering [N-UNCOUNT-U4] Requirements engineering is the practice of creating and documenting requirements for software and other computer systems.
response [N-COUNT-U4] A response is information provided by software upon search or request.
restructuring [N-UNCOUNT-U15] Restructuring is the process of updating a system while keeping the same functionality and level of abstraction.
revamping [N-UNCOUNT-U15] Revamping is the process of updating the user interface of a program without changing the program’s structure.
reverse engineering [N-UNCOUNT-U15] Reverse engineering is the process of analyzing an existing software system and creating a new version of the system at a higher level of abstraction.