algorithmic cost estimation model (2 kinds, 7 facts) - An approach to cost estimation such as COCOMO or function points, that use mathematical formulas whose parameters are based on industrial experience
attribute^2 (2 kinds, 5 facts) - A detail in the requirements of a system
behaviour (3 facts) - The way an object or system acts and reacts, possibly changing its state
combinatorial explosion (3 facts) - In the context of testing, the observation that the number of required tests for exhaustive testing will increase exponentially as the number of inputs increases
component (12 kinds, 5 facts) - Any piece of software or hardware that has a clear role and can be isolated, allowing you to replace it with a different component with equivalent functionality
connection (1 kind, 5 facts) - The existence of a communications channel between two computers, typically a client and server
critical path (5 facts) - A path through a PERT chart indicating the minimum time in which it is possible to complete a project, and the tasks that, if delayed, will delay the whole project
design decision (6 facts) - A decision made in the process of design which involves listing design options, evaluating them according to pre-determined criteria, and choosing the alternative that has the best cost-benefit trade-off
design option (3 facts) - An alternative solution to a design issue
design space (3 facts) - The space of possible design options
dialog^2 (3 facts) - The back-and-forth interaction between user and computer
domain^2 (4 facts) - A general field of business or technology in which users work, and which is learned by the software engineer during domain analysis
economies of scale (4 facts) - Sub-linear growth in effort as size increases
equivalence class (4 facts) - A set of inputs that a tester believes will be treated similarly by reasonable algorithms
event (7 kinds, 4 facts) - In a state diagram, something that causes a system or object to change state. May be a message, the passage of elapsed time, a condition becoming true, or completion of an activity
force (4 facts) - In a pattern, an issue or concern that you need to consider when solving the problem, including, criteria for evaluating a good solution
goal (3 facts) - What the user hopes to accomplish by using a system
hook (6 facts) - An aspect of the design deliberately added to allow other designers to add additional functionality. It does nothing in the basic version of the system, but is designed to be implemented or overridden when the system is extended or reused
inheritance (2 kinds, 4 facts) - The possession by one class of elements defined in another class, by virtue of the fact that the former class is defined to be a subclass of (to extend) the latter
message (1 kind, 4 facts) - Any information sent as a component interacts with another, including using procedure calls, or network communication
methodology (2 kinds, 7 facts) - A description of a process; it usually prescribes how to do things in a step by step manner
milestone (4 facts) - An important deadline date, at which a specific event may occur, and when a specific deliverable may be required
multiplicity (5 kinds, 6 facts) - Information placed at each end of an association indicating how many instances of one class can be related to instances of the other class
note (3 facts) - A small block of text embedded in a UML diagram
noun phrase (4 facts) - A string of nouns, or a noun modified by one or more adjectives
paradigm (3 kinds, 3 facts) - An approach to software design and programming
pattern (4 kinds, 6 facts) - A widely understood solution to a particular type of problem
priority (5 facts) - An ordering that states which qualities override others in those cases where you must make compromises
problem (4 kinds, 5 facts) - In the broad context of software engineering, a difficulty, challenge, need or desire faced by a customer that is to be solved by developing software
process (47 kinds, 3 facts) - Anything that operates for a period of time, normally consuming resources during that time and using them to create a useful result
process model (8 kinds, 6 facts) (software process model) - A general approach for organizing a project into activities; an aid to thinking, not a rigid prescription of the way to do things
process^2 (2 kinds, 3 facts) - A running thread of execution in a computer
requirement (4 kinds, 31 facts) - 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
resource (3 facts) - Anything consumed in the development, operation or maintenance of a product or process
responsibility (9 kinds, 7 facts) - Something a system is required to do that is allocated to a particular class
scope (1 kind, 3 facts) - The region of a source text over which a declaration holds
scope^2 (8 facts) - The extent of a software project
system (6 kinds, 13 facts) - A logical entity, having a set of definable responsibilities or objectives, and consisting of hardware, software or both
test (3 facts) - A particular run of a test case on a particular version of the system
test case (4 kinds, 6 facts) - An explicit set of instructions designed to detect a particular class of defect in a software system, by bringing about a failure
thread (1 kind, 7 facts) - A path of execution that can run concurrently with other paths of execution
trigger question (5 facts) - A question in a brainstorming session for which the participants can provide simple one-line answers that are more than just numbers or yes/no responses
use case (4 kinds, 28 facts) - A way in which a system can be used, described as a step-by-step sequence of actions, along with the system's response and certain other information
Object Oriented Software Engineering View all facts Glossary Help
