Glossary of Software Engineering Process Terms
Note: I've compiled the following glossary of software
engineering process terms to help software teams apply a common language to
address the challenges of iterative and agile development. So as not to reinvent
the wheel and create "yet another method method", I've borrowed heavily
from available open and commercial standards such as the UML and various UML
profiles, the Rational Unified Process and some of my own prior work. I've
referenced the standard or other work in each definition where applicable. Any
definition not so referenced is a definition of my own recent making. References
form the UML and its various official OMG profiles are indicated by 
.
Dean Leffingwell, 2003
[A] B C D
E F G H I J
K L M N O
P Q R S T
U V W X Y Z 
-
- An action by which the customer accepts ownership of software products as a partial or complete performance of a contract.4
-
- Formal tests deveeloped by the customer or product manager and conducted to determine whether or not a system satisfies its acceptance criteria and enable the customer to determine whether or not to accept the system..
- activity
- Work Definition describing what a Process Role performs.
Activities are the main element of work in a software process.[5]
- actor (instance)
- Someone or something, outside the system that interacts with the system.[2]
- actor class
- Defines a set of
actor instances, in which each actor instance plays the same role in
relation to the system.[2]
- A coherent set of roles that users of use cases play when interacting with these use cases. An actor has one role for each use case with which it communicates.[1]
- actor goal list
- Lowest precision view of a set of use cases is the Actors-Goals list. The
list of primary actors and goals they have with respect to the system.
Useful at the start of the project when you are prioritizing the use cases
and allocating work to the teams. 7 (p. 126)
Acceptance
Acceptance Testing
Administrator
Application
 | Related capabilities that satisfy a customer need. A set of interacting objects that provide a well-defined set of services that implement capabilities required by a customer. 6 |
Archive
| RP: To duplicate the database, documents, and all related files in a project for the purpose of restoring them at a later time. |
Attachment
Administrator Group
Annotatable
Annotation
Application
| Related capabilities that satisfy a customer need. A set of interacting
objects that provide a well-defined set of services that implement
capabilities required by a customer. 1 (p. 504) |
An arbiter is a property of a test case or a test
suite to evaluate test results and to assign the overall verdict of a test
case or test suite respectively.[4]The
organizational structure of a system. An architecture can be recursively
decomposed into parts that interact through interfaces, relationships that
connect parts, and constraints for assembling parts..[1]Archive
Attachment
Attribute Label
Attribute Type
Attribute Value
Author
-
- The user responsible for creating or modifying a work product.
- baseline
- A reviewed and approved release of artifacts that constitutes an agreed basis for further evolution or development and that can be changed only through a formal procedure, such as configuration control.[2]
- beta testing
- Pre-release testing in which a sampling of the intended customer base tries out the product.[2]
- build
- An operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the final product.[2]
- business rule
- A declaration of policy or condition that must be satisfied within the business.[2]
A B [C] D
E F G H I J
K L M N O
P Q R S T
U V W X Y Z
- change management
- The activity of controlling and tracking changes to artifacts. [2]
- change request (CR)
- A general term for any request from a stakeholder to change an artifact or process. Documented in the Change Request is information on the origin and impact of the current problem, the proposed solution, and its cost. [2] See also enhancement request, defect.
- comment
- An annotation attached to an element or a collection of elements. An annotation has no semantics.[1]
- component
- A physical,
replaceable part of a system that packages implementation and conforms to
and provides the realization of a set of interfaces. A component represents
a physical piece of implementation of a system, including software code
(source, binary or executable) or equivalents such as scripts or command
files.[1]
- configuration
- (1) general: The arrangement of a system or network as defined by the nature, number, and chief characteristics of its functional units; applies to both hardware or software configuration.[2]
- (2) The requirements, design, and implementation that define a particular version of a system or system component. See configuration management.
- configuration item
- An entity in a configuration that satisfies an end-use function and can be uniquely identified at a given reference point. [2]
- configuration management (CM)
- A supporting process whose purpose is to identify, define, and baseline items; control modifications and releases of these items; report and record status of the items and modification requests; ensure completeness, consistency and correctness of the items; and control storage, handling and delivery of the items. [2]
- construction
- The third phase of the Unified Process, in which the software is brought from an executable architectural baseline to the point at which it is ready to be transitioned to the user community.[2]
- customer
- A person or organization, internal or external to the producing organization, who takes financial responsibility for the system. In a large system this may not be the end user. The customer is the ultimate recipient of the developed product and its artifacts. See also stakeholder.[2]
- cycle
- One complete pass through the four phases: inception, elaboration, construction and transition. The span of time between the beginning of the inception phase and the end of the transition phase.[2]
A B C [D]
E F G H I J
K L M N O
P Q R S T
U V W X Y Z
- data pool
- A data pool is a collection of values. It is used by test components as a source of values for the execution of test cases. Data pools can be represented by utility parts or be logically described by constraints.[4]
- defect
- An anomaly, or flaw, in a delivered work product. Examples include such things as omissions and imperfections found during early lifecycle phases and symptoms of faults contained in software sufficiently mature for test or operation. A defect can be any kind of issue you want tracked and resolved.[2]
A relationship between two modeling elements,
in which a change to one modeling element (the independent element)
will affect the other modeling element (the dependent element).[1]The part of the software development process whose primary purpose is
to decide how the system will be implemented. During design, strategic
and tactical decisions are made to meet the required functional and
quality requirements of a system.[1] A set of partially ordered steps performed for a given purpose during
software development, such as constructing models or implementing models.[1] An area of knowledge or activity characterized by a set of concepts
and terminology understood by practitioners in that area.[1]A B C D
[E] F G H I J
K L M N O
P Q R S T
U V W X Y Z
- elaboration
- The second phase of the process where the product vision and its architecture are defined.[2]
- element
- An element describing one aspect of a software engineering process.[5]
- enhancement request
- A type of stakeholder request that specifies a new feature or functionality of the system. See also change request.[2]
- event
- The specification of a significant occurrence that has a location in time
and space. In the context of state diagrams,
an event is an occurrence that can trigger a transition.[1]
- exit action
- An action executed upon exiting a state in a state machine regardless of the transition taken to exit that state.[1]
- extend
- A relationship from an extension use case to a base use case, specifying how
the behavior defined for the extension use case can be inserted into the
behavior defined for the base use case.[1]
- extend-relationship
- An extend-relationship from a use-case class A to a use-case class B indicates that an instance of B may include (subject to specific conditions specified in the extension) the behavior specified by A. Behavior specified by several extenders of a single target use case can occur within a single use-case instance.[2]
A B C D E
[F] G H I J K
L M N O P
Q R S T U
V W X Y Z
-
failure
-
- The inability of a system or component to perform its required functions within specified performance requirements [IEEE90]. A failure is characterized by the observable symptoms of one or more defects that have a root cause in one or more faults.8
- feature
- An externally observable service provided by the system which directly fulfills a stakeholder need.[3]
- Functional Requirement
- A system behavior observable by a user – a systems inputs, outputs and the functions it provides.[3]
- FURPS
- Functionality, Usability, Reliability, Performance, Supportability: this acronym represents categories for assessing product quality.[3]
A B C D E
F [G H] I J K
L M N O P
Q R S T U
V W X Y Z
- guard condition
- A condition that must be satisfied in order to enable an associated transition to fire.[2]
- guidance
-
A description of how to work with a particular work product, including how to create and revise the work product. Guidance (guidelines) may include techniques, procedures, standards, tips, templates of work products, examples of work products, definitions, and so on.
- GUI
- Graphical User Interface
- hypertext
- Text in a document that contains a hidden link to other text. You can click a mouse on a hypertext word and it will take you to the text designated in the link. Hypertext is used in Windows help programs and CD encyclopedias to jump to related references elsewhere within the same document. The wonderful thing about hypertext, however, is its ability to link—using HTTP over the Web—to any Web document in the world, yet still require only a single mouse click to jump clear around the world.[2]
A B C D E
F G H [I J] K
L M N O P
Q R S T U
V W X Y Z
- implementation
- A discipline in the software-engineering process, whose purpose
is to implement and unit test the classes.[2]
- A definition of how something is constructed or computed. For example, a class is an implementation of a type, a method is an implementation of an operation.[1]
- inception
- The first phase of the Unified Process, in which the seed idea, request for proposal, for the previous generation is brought to the point of being (at least internally) funded to enter the elaboration phase.[2]
- include
- A relationship from a base use case to an inclusion use case, specifying how
the behavior defined for the inclusion use case can be inserted into the
behavior defined for the base use case.[1]
- include-relationship
- An include-relationship is a relationship from a base use case to an inclusion use case, specifying how the behavior defined for the inclusion use case is explicitly inserted into the behavior defined for the base use case.[2]
increment
| A small and manageable part of the system, usually the delta or difference between two successive builds. Each iteration will result in at least one (new) build and will thus add an increment to the system. However, a sequence of builds may be created within an iteration, each one adding a small increment to the system. 8 (p.445) |
The mechanism by
which more specific elements incorporate structure and behavior of more
general elements related by behavior.[1]A transition signifying a response to an
event without changing the state of an object.[1]A B C D E
F G H I J [K]
L M N O P
Q R S T U
V W X Y Z
- keyword
- A predefined word reserved for Java, for example, return, that may not be used as an identifier.[2]
A B C D E
F G H I J K
[L] M N O P
Q R S T U
V W X Y Z
A B C D E
F G H I J K
L [M] N O P
Q R S T U
V W X Y Z
- management
- A discipline in the software-engineering process, whose purpose is to plan and manage the development project.[2]
- method
- (1) A regular and systematic way of accomplishing something; the detailed, logically ordered plans or procedures followed to accomplish a task or attain a goal. (2) UML 1.1: The implementation of an operation, the algorithm or procedure that effects the results of an operation.[2]
- The
implementation of an operation. It specifies the algorithm or procedure
associated with an operation[1]
- module
- A software unit of storage and manipulation. Modules include source code
modules, binary code modules, and executable code modules.[1]t.
A B C D E
F G H I J K
L M [N] O P
Q R S T U
V W X Y Z
- name
- A string used to identify a model element.[1]
- namespace
- A part of the model in which the names may be defined and used. Within a
namespace, each name has a unique meaning. .[1]
- nonfunctional requirement
- An indirectly observable aspect of system behavior such as usability, reliability, performance and supportability.[3]
A B C D E
F G H I J K
L M N [O] P
Q R S T U
V W X Y Z
- object
- An entity with a well-defined boundary and identity that encapsulates state
and behavior. State is represented by attributes
and relationships, behavior is
represented by operations, methods,
and state machines. [1]An object is an
instance of a class. See class,
instance.
- operation
- A service that can be requested from an object to effect behavior. An
operation has a signature, which may
restrict the actual parameters that are possible.[1]
- organization unit
- A collection of business workers, business entities, relationships, business use-case realizations, diagrams, and other organization units. It is used to structure the business object model by dividing it into smaller parts.[2]
- originator
- An originator is anyone who submits a change request (CR). The standard change request mechanism requires the originator to provide information on the current problem, and a proposed solution in accordance with the change request form.[2]
- output
- Any artifact that is the result of a process step. [2] See deliverable.
A B C D E
F G H I J K
L M N O [P]
Q R S T U
V W X Y Z
- package
- A general purpose mechanism for organizing elements into groups. Packages
may be nested within other packages.[1]
- parameter
- The specification of a variable that can be changed, passed, or returned. A
parameter may include a name, type, and direction. Parameters are used for
operations, messages, and events.[1]
- parent
- In a generalization relationship, the
generalization of another element, the child.[1]
- parent class
- The class from which another bean or class inherits data, methods, or both.[2]
- participates
- The connection of a model element to a relationship or to a reified relationship. For example, a class participates in an association, an actor participates in a use case.[1]
- postcondition
- A textual description defining a constraint on the system when a use case has terminated.[2]
- PRD
- Product Requirements Document
- precondition
- A textual description defining a constraint on the system when a use case may start.
- process
- A set of partially ordered steps intended to reach a goal; in software engineering the goal is to build a software product or to enhance an existing one; [2]
- process component
-
Process Component is a coherent grouping of process Model Elements organized from a given vantage point such as a discipline, for example, testing, or the production of some specific work product, for example, requirements management.[5]
- product
- Software that is the result of development, and some of the associated artifacts (documentation, release medium, training).[2]
- product champion
- A high-ranking individual who owns the vision of the product and acts as an advocate between development and the customer.
- product-line architecture
- Defines element types, how they interact, and how the product functionality is mapped to them. It may also go further by defining some of the instances of the architecture elements. This term generally applies to a set of products within an organization or company. [2]
- product requirements document (PRD)
- A high level description of the product (system), its intended use, and the set of features it provides.[3]
- project
- Projects are performed by people, constrained by limited resources, and planned, executed, and controlled. A project is a temporary endeavor undertaken to create a unique product or service. Temporary means that every project has a definite beginning and a definite ending. Unique means that the product or service is different in some distinguishing way from all similar products and services. Projects are often critical components of the performing organizations' business strategy.[2]
- project manager
- The role with overall responsibility for the project. The Project Manager needs to ensure tasks are scheduled, allocated and completed in accordance with project schedules, budgets and quality requirements.[2]
- prototype
- A release that is not necessarily subject to change management and configuration control.[2]
A B C D E
F G H I J K
L M N O P
[Q] R S T U
V W X Y Z
- QA
- Quality Assurance
- quality assurance (QA)
- The function of Quality Assurance is the responsibility of (reports to) the Project Manager and is responsible for ensuring that project standards are correctly and verifiably followed by all project staff.[2]
A B C D E
F G H I J K
L M N O P
Q [R] S T U
V W X Y Z
- rationale
- A statement, or explanation of the reasons for a choice.[2]
- reference
- (1) A denotation of a model element. (2)
A named slot within a classifier
that facilitates navigation to other classifiers. Synonym: pointer.[1] - release
- A subset of the end-product that is the object of evaluation at a major milestone. A release is a stable, executable version of product, together with any artifacts necessary to use this release, such as release notes or installation instructions. A release can be internal or external. An internal release is used only by the development organization, as part of a milestone, or for a demonstration to users or customers. An external release (or delivery) is delivered to end users. A release is not necessarily a complete product, but can just be one step along the way, with its usefulness measured only from an engineering perspective. Releases act as a forcing function that drives the development team to get closure at regular intervals, avoiding the "90% done, 90% remaining" syndrome. See also prototype, baseline.[2]
- release candidate
- A release candidate is an iteration of a software system which meets established iteration criteria and is ready for further evaluation to determine suitability for being released to external users.
- release manager
- A release manager is responsible for ensuring that all software assets are controlled and configurable into internal and external releases as required.[2]
- report
- An automatically generated description, describing one or several artifacts. A report is not an artifact in itself. A report is in most cases a transitory product of the development process, and a vehicle to communicate certain aspects of the evolving system; it is a snapshot description of artifacts that are not documents themselves.[2]
- repository
- A storage place for object models, interfaces, and implementations.[1]
- requirement
- A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document. [3].
- A desired
feature, property, or behavior of a system.[1]
- requirement attribute
- Information associated with a particular requirement providing a link between the requirement and other project elements—for example, priorities, schedules, status, design elements, resources, costs, hazards.[3]
- requirement type
- A categorization of requirements—for example, stakeholder need, feature, use case, supplementary requirement, test requirement, documentation requirement, hardware requirement, software requirement, and so on—based on common characteristics and attributes. [3]
- requirements
- A discipline in the software-engineering process, whose purpose is to define what the system should do. The most significant activities are to develop a vision, a use-case model, and software requirements specifications.[2]
- requirements management
- A systematic approach to eliciting, organizing and documenting the requirements of the system, and establishing and maintaining agreement between the customer and the project team on the changing requirements of the system. [3]
- requirements tracing
- The linking of a requirement to other requirements and to other associated project elements.[3]
- result
- Synonym of output. See also deliverable.[2]
- resurrect
- Synonymous with deserialize.[2]
- reuse
- Further use or repeated use of an artifact[2]
- The use of a pre-existing artifact.[1]
- review
- A review is a group activity carried out to discover potential defects and to assess the quality of a set of artifacts.[2]
- risk
- An ongoing or upcoming concern that has a significant probability of adversely affecting the success of major milestones.[2]
- role
- A definition of the behavior and responsibilities of an individual, or a set of individuals working together as a team, within the context of a software engineering organization..[2]
- RUP
- Rational Unified Process[2]
A B C D E
F G H I J K
L M N O P
Q R [S] T U
V W X Y Z
- sandbox
- A restricted environment, provided by the Web browser, in which Java applets run. The sandbox offers them services and prevents them from doing anything naughty, such as doing file I/O or talking to strangers (servers other than the one from which the applet was loaded). The analogy of applets to children led to calling the environment in which they run the sandbox.[2]
- scenario
- A use case execution wherein a specific user executes the use case in a specific way.[3]
- A specific
sequence of actions that illustrates behaviors. A scenario may be used to
illustrate an interaction or the execution of a use case instance.[1]
.
- Scope
- The achievable scope of a project or iteration reflects the features that can be accomplished in a given time with a given resource.[3]
- scope management
- The process of prioritizing and determining the set of requirements that can be implemented in a particular release cycle, based on the resources and time available. This process continues throughout the lifecycle of the project as changes occur. [3]
- sequence diagram
- A diagram that shows object interactions arranged in time sequence. In
particular, it shows the objects participating in the interaction and the
sequence of messages exchanged. Unlike a collaboration diagram, a sequence
diagram includes time sequences but does not include object relationships. A
sequence diagram can exist in a generic form (describes all possible scenarios)
and in an instance form (describes one actual scenario). Sequence diagrams
and collaboration diagrams express similar information, but show it in
different ways. [1]
- software architecture
- Software architecture encompasses:
| the significant decisions about the organization of a software system |
| the selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements |
| the composition of the structural and behavioral elements into progressively larger subsystems |
| the architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition |
A declarative description of what something is or does. [1]A condition or situation during the life of an object during which it
satisfies some condition, performs some activity, or waits for some event.[1]A state machine
specifies the behavior of a model element,
defining its response to events and the life cycle of the object.[2]An
atomic and fine-grained Model Element used to decompose Activities.
Activities are partially ordered sets of Steps.[5]
The passing of information from one instance to another, such as raising a signal
or invoking an operation. The receipt of a
signal is normally considered an event.[1]
.
A sequence of text characters. The details of string representation depend
on implementation, and may include character sets that support international
characters and graphics.[1]A state in a state
machine which is equivalent to a composite
state but its contents are described by another state machine.[1]A state that is part of a composite state.
See concurrent substate, disjoint
substate.[1]A model
element which has the semantics of a package,
such that it can contain other model elements, and a class,
such that it has behavior. The behavior of the subsystem is provided by
classes or other subsystems it contains. A subsystem realizes one or more
interfaces, which define the behavior it can perform.[2](1) A collection of connected units that are organized to accomplish a
specific purpose. A system can be described by one or more models,
possibly from different viewpoints. Synonym: physical system. (2) A
top-level subsystem.[1]The
system under test (SUT) is a part and is the system, subsystem, or
component being tested. A SUT can consist of several objects. The SUT is
exercised via its public interface operations and signals by the test
components. No further information can be obtained from the SUT as it is a
black-box.[4]A B C D
E F G H I J
K L M N O
P Q R S [T]
U V W X Y Z
- tagged value
- The explicit definition of a property as a name-value pair. In a tagged
value, the name is referred as the tag. Certain tags are predefined in the
UML; others may be user defined. Tagged values are one of three
extensibility mechanisms in UML. See constraint,
stereotype.[1]
- target (for test)
- A build that is an object for testing. [2]
- team leader
- The team leader is the interface between project management and developers. The team leader is responsible for ensuring that a task is allocated and monitored to completion. The team leader is responsible for ensuring that development staff follow project standards, and adhere to project schedules.[2]
- technical authority
- The project's technical authority has the authority and technical expertise to arbitrate on if, and how, a change request is to be implemented. The technical authority defines change tasks, and estimates the effort of engineering the work tasks, corresponding to a change request.[2]
- test case
- A test case is a specification of one case to
test the system, including what requirement to test with which input,
result, and under which conditions. A test case is defined in terms of
sequences, alternatives, loops and defaults of stimuli to and observations
from the SUT. It implements a test objective. A test case may invoke other
test cases.[4]
- test coverage
- The degree to which a given test or set of tests addresses all specified test cases for a given system or component.
- test component
- A test component is a class of a test system that
objects realize the behavior of a test case. A test component has a set of
interfaces via which it may communicate via connections with other test
components or with the SUT.[4]
- test configuration
- A test configuration
is a collection of test component objects and of connections between the
test component objects and to the SUT. The test configuration defines both
(1) test component objects and connections when a test case is started
(the initial test configuration) and (2) the maximal number of test
component objects and connections during the test execution..[4]
- test driver
- A software module or application used to invoke a test item and, often, provide test inputs (data), control and monitor execution, and report test results. A test driver automates the execution of test procedures.
- test item
- A build which is an object of testing.
- test objective
- A test
objective is a named element describing what should be tested. It is
associated to a test case.[4]
- test stimulus for ref
- A stimulus
is test data sent to the SUT in order to control it and to make assessments
about the SUT when receiving the SUT reactions to these stimuli..[4]
- test procedure
- A test procedure is a set of detailed instructions for the set-up, execution, and evaluation of results for a given test case.
- time
- A value representing an absolute or relative moment in time.[1]
- time event
- An event that denotes the time elapsed since the current state was entered.
[1]
- time expression
- An expression that resolves to an absolute or relative value of time.[1]
- timeboxing
- The approach to the management of an iteration's schedule recommended in the RUP: having initially established the scope and schedule for an iteration, the project manager is encouraged to actively manage that scope (and the resources committed to the iteration) so as to meet the planned iteration end date, rather than slipping the end date to accommodate the originally planned scope, if development takes longer than planned. In the RUP, reduction of scope is preferred to addition of resources to manage a slipping schedule. The motivations for this approach are to make the results of an iteration visible to the stakeholders and to assess the iteration, so that the lessons learned may be applied to subsequent iterations[2]
- timing mark
- A denotation for the time at which an event or message occurs. Timing marks
may be used in constraints.[1]
- trace
- A dependency that indicates a historical or process relationship between two
elements that represent the same concept without specific rules for deriving
one from the other.[1]
- traceability
- The ability to trace a project element to other related project elements, especially those related to requirements. Project elements involved in traceability are called traceability items.
- traceability item
- Any project element which needs to be explicitly traced from another project element in order to keep track of the dependencies between them. [2]
- transaction
- A unit of processing consisting of one or more application programs initiated by a single request. A transaction can require the initiation of one or more tasks for its execution.[2]
- transaction processing
- A style of computing that supports interactive applications in which requests submitted by users are processed as soon as they are received. Results are returned to the requester in a relatively short period of time. A transaction processing system supervises the sharing of resources for processing multiple transactions at the same time.[2]
- transition
- The fourth phase of the process in which the software is turned over to the user community.[2]
- A relationship
between two states indicating that an object in
the first state will perform certain specified actions and enter the second
state when a specified event occurs and specified conditions are satisfied.
On such a change of state, the transition is said to fire.[1]
- trigger
- With the exception of
the initial transition[1], all behavior in a state machine[1] is
triggered by the arrival of events on one of an object's interfaces. Therefore,
a trigger defines those events from which interfaces will cause the transition
to be taken. The trigger is associated with the interface on which the
triggering event is expected to arrive. Moreover, a transition can have multiple
triggers such that an event that satisfies any one of the triggers will cause
the transition to be taken.[1]
- type
- Description of a set of entities which share common characteristics, relations, attributes, and semantics.[2]
- A stereotype of
class that is used to specify a domain of instances (objects) together with
the operations applicable to the objects. A type may not contain any
methods. [1].
A B C D E
F G H I J K
L M N O P
Q R S T [U]
V W X Y Z
- UI
- User Interface
- UML
- Unified Modeling Language
- U
- Unified Modeling Language (UML)
- A language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system [1]
- usage
- A dependency in which one element (the client) requires the presence of another element (the supplier) for its correct functioning or implementation.[1]
- use case
- A
description of system behavior, in terms of sequences of actions between an
actor and the system. A use case
should yield an observable result of value to an actor.
A use case contains a main course and all alternate flows of events related to producing the
"observable result of value".
More formally, a use case defines a set of use-case instances or scenarios. - The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. See use-case instances.[1]
- use-case diagram
- A diagram that shows the relationships among actors and use cases within a system.[1]
- use-case instance
- The performance of a sequence of actions being specified in a use
case. An instance of a use case.[1]
A use-case instance is more specific than a use case - actors are replaced by specific persons or actor instances, and only one path is taken through the possible alternate flows of the use case. - use-case model
- A model that describes a system’s functional requirements in terms of use cases.[1]
- use-case package
- A use-case package is a collection of use cases, actors, relationships, diagrams, and other packages; it is used to structure the use-case model by dividing it into smaller parts.
- use-case realization
- A use-case realization describes how a particular use case is realized within the design model, in terms of collaborating objects.[2]
- use-case section
- A use-case section is any section of a use case, including preconditions, postconditions, subflows, steps, and text. Use-case sections are commonly used as traceability items.[2]
- use-case view
- An architectural view that describes how critical use cases are performed in the system, focusing mostly on architecturally significant components (objects, tasks, nodes). [2] In the RUP, it is a view of the use-case model.
- user interface (UI)
- (1) The hardware, or software, or both that enables a user to interact with a computer. (2) The term user interface typically refers to the visual presentation and its underlying software with which a user interacts.[2]
A B C D E
F G H I J K
L M N O P
Q R S T U
[V] W X Y Z
- validation action
- A validation action evaluates the status of the execution of a test case by assessing the SUT observations and/or additional characteristics/parameters of the SUT. A validation action is performed by a test component and sets the local verdict of that test component.[4]
- value
- An element of a type domain.[1]
- variable
- (1) A storage place within an object for a data feature. The data feature is an object, such as number or date, stored as an attribute of the containing object. (2) A bean that receives an identity at run time. A variable by itself contains no data or program logic; it must be connected such that it receives run-time identity from a bean elsewhere in the application.[2]
- verdict
- Verdict is the assessment of the correctness of the SUT. Test cases yield verdicts. Verdicts can also be used to report failures in the test system. Predefined verdict values are pass, fail, inconclusive and error.[4]
- version
- A variant of some artifact; later versions of an artifact typically expand on earlier versions.[2]
- view
- A simplified description (an abstraction) of a model, which is seen from a given perspective or vantage point and omits entities that are not relevant to this perspective.[2]
- A projection of a model, which is seen from a given perspective or vantage point and omits entities that are not relevant to this perspective.[1]
- vision
- The user's or customer's view of the product to be developed, specified at the level of key stakeholder needs and features of the system.
A B C D E
F G H I J K
L M N O P
Q R S T U
V [W X Y Z]
- waterfall model
- IEEE90] defines the waterfall model as, "A model of the software development process in which the constituent activities, typically a concept phase, requirements phase, design phase, implementation phase, test phase, and installation and checkout phase, are performed in that order, possibly with overlap but with little or no iteration."
- Widget
- In this context, a generic term for something that can be put on a window such as a button, scrollbar, label, listbox, menu, or checkbox.[2]
- work definition
- Model Element of a process describing the execution, the operations performed, and the transformations enacted on the Work Products by the roles. Activity, Iteration, Phase, and Lifecycle are kinds of work definition. [5]
- work product
- Work Product is a description of a piece of information or physical entity produced or used by the activities of the software engineering process. Examples of work products include models, plans, code, executables, documents, databases, and so on. [5]
- work breakdown structure
- The planning framework; a project decomposition into units of work from which cost, artifacts, and activities can be allocated and tracked.[2]
- work guideline
- A description which provides practical guidance on how to perform an activity or set of activities. It usually considers techniques which are useful during the activity.[2]
- workflow
- The sequence of activities performed in a business that produces a result of observable value to an individual actor of the business.[2]
- -------------------------------------------
- Bibliography
[1]
Object Management Group. 2001. Unified Modeling Language, V1.1
[3] Leffingwell, Dean and
[5] Object Management Group. November 2003. Software Process Engineering Metamodel Specification V1.0, Needham, MA.
[6] Goldberg, Adele and Rubin, Kenneth S. Succeeding With Objects, Decision Frameworks for Project Management. Addison-Wesley, 1995.
7 Cockburn, Alistair Agile Software Development. Addison-Wesley, 2002.
8 Jacobson, Ivar, Booch, Grady and Rumbaugh, James. The Unified Software Development Process. Addison-Wesley, 1999.
