Block 1 Glossary Flashcards
These cards are a copy of the glossary provided by TM354. Except where definitions are 'see x', these cards have been omitted. (201 cards)
1
Q
Abstraction
A
The process of describing the essential features of a problem and ignoring other details. It permits you to concentrate on a problem at some level of generalisation, without regard to irrelevant detail. It also permits you to work with concepts, terms and models that are familiar in the problem environment (or domain).
2
Q
Activity
A
In UML, an activity is an ongoing non-atomic execution (contrast with action) within a state machineor within an activity diagram; in a given context, activities result in one or more actions.
In a software development process, it is a unit of work comprising one or more tasks that someone may be asked to perform.
3
Q
Activity Diagram
A
A representation of a workflow through activity states or action states and in which most or all of the transitions are triggered by completion of an activity in the source states; an activity diagram can be used to represent the workflows within the business domain.
4
Q
Actor
A
A representation of users of a software system in a particular role, when interacting with use cases. An actor can also represent the role of an external system that interacts with a software system.
5
Q
Aglie
A
6
Q
Agile UP
A
A version of UP where the initial disciplines (business/domain model, requirements, analysis and design) are collapsed into a single ‘model’ discipline and where iterations are short (weeks rather than months) and frequent; product is delivered incrementally if at all possible; design and implementation do not wait until all the requirements are found.
7
Q
Ambiguity
A
Open to several interpretations.
8
Q
Analysis
A
The term analysis is often used as a generic term for the activities that precede design, the process of eliciting the requirements of a system from the user (requirements elicitation), and then generating the requirements specification document that identifies (among other things) what the software should do (its functional requirements) and the environment in which it must work. In this module we use the term analysis to refer specifically to a set of activities that follow an initial requirementsphase: modelling how the structure and behaviour of the system will meet its specification from a user’s perspective. (See also requirements, design, implementation and testing).
9
Q
Analysis Model
A
An initial representation of the structure of a software solution by a class diagram; it represents analysis classes, their associations and constraints.
10
Q
Association
A
11
Q
Business Event
A
12
Q
Business Process
A
Definition of what gets done in the business: by whom, in what order, needing what and with what consequences.
13
Q
Business Rule
A
A constraint on how the business is run; that is, a constraint on the business processes.
14
Q
Caller
A
Component that makes a procedure call in a call-return architecture.
15
Q
Circular Dependency
A
A series of two or more dependencies between different things (typically modules within a software system) that form a closed loop. If module A depends on module B which depends on module C, then a circular dependency arises if module C depends on module A.
16
Q
Client
A
In software development, the term refers to the person (or company) who commissions and pays for a piece of software to be developed or to be purchased as a package (in this context the term client is synonymous with the term customer).
In programming, the term often refers to the method/class/object that uses the methods of another class/object (the supplier or server).
In network programming, the term refers to a program/process running on one computer that can obtain services from a server program running (usually) on another computer.
17
Q
Cohesion
A
A way of describing how closely the activities within a single module are related to each other. A cohesive module should, ideally, do just one thing. In software development, high cohesion is preferred to low cohesion as it results in a more flexible software system because each module performs clearly defined operations/tasks.
18
Q
Commitment
A
A move of the planning game that decides what to do next.
19
Q
Communication Diagram
A
A UML interaction diagram that focuses on the structural aspect (instances and links) of an interaction. In previous versions of UML a communication diagram was known as a collaboration diagram.
20
Q
Complexity
A
A complex system consists of a number of parts with a large number of relationships between them. A complex program is one that is difficult to understand.
21
Q
Component
A
In general, this refers to an identifiable part of a system. For its use in connection with software systems, see software component.
22
Q
CASE
A
Computer-aided Software Engineering
The use of specialised application programs (tools) that provide some form of automated support during the development of a software system for the benefit of its eventual implementation. Consequently, it includes one or more methods, as well as their accompanying techniques and notations, used for activities such as analysis and design.
23
Q
Concept(ual) Model
A
The structural model that represents the static part of the domain: the concepts and their relationships.
24
Q
Configuration
A
All the modules (components) which together make up an executable software system. It is also a term for the collection of configuration items.
25
Configuration Item
The configuration items are the items produced during the development and maintenance of software, which are stored, retrieved, changed, stored again, and so on. These include: use case diagrams and other UML diagrams; individual Java programs or classes, or the compiled versions of these; architectures and patterns; test plans and test cases.
26
Configuration Management
The task of managing configuration items, which involves identifying the components of a continuously evolving system (the configuration) at discrete points in time, for the purposes of controlling changes to the configuration, and maintaining integrity and traceability throughout the system’s lifetime.
27
Conformance Testing
Testing that the software product conforms to its requirements.
28
Construction
In UP, phase when the final product is implemented.
29
Context Dependency
A service required by a module in order for it to work.
30
Contract
A legal document describing the obligations of two parties entering into an agreement; important contract issues include confidentiality and intellectual property rights. In a software project, a contract exists between the customer (client) and developer (supplier) for the provision of a software product. Also, a way of describing what each task, activity or operation commits to achieve by stating the pre- and postconditions. (See also Design by Contract.)
31
Coupling
A measure of interconnection among modules in a software system. In software development, low coupling is preferred to high coupling as it results in a more flexible software system. (See also encapsulation.)
32
Culural Requirement
A non-functional requirement relating to the people involved in the product’s development and operation.
33
Decision Nodes
In an activity diagram a node that is used to indicate alternative transitions that can be made when leaving an activity; it is represented by a diamond shape. A decision node has a single incoming transition; the guards on outgoing transitions are mutually exclusive.
34
Decomposition
Splitting a problem into smaller and smaller parts or chunks until each one can be comprehended or dealt with by an individual. In software we identify a number of different activities or tasks that an individual or a group of individuals might perform.
| (See also partition.)
35
Deliverable
An output, such as a design document or source code, of some software development activity whose production gives evidence of the completion of the activity.
36
Denial of Use of Service
Loss of Access
Attack consisting of the denial of service to authorised users.
37
Deployment
Configuring code to give a runnable system.
38
Deployment View
The identification of all the nodes that comprise a distributed software system, the components that are stored on each node and the objects that are stored there.
39
Derivation
A version of a configuration item based on other configuration items, which might have to be changed if the original item changes.
40
Design
The process of determining how to build an artefact that meets a set of objectives that are normally identified during analysis. It is one of the four basic technical activities within a software development process (see also analysis, implementation and testing).
41
DbC
Design by Contract
The process of developing software based on the notion of contracts between objects, which are expressed as assertions.
42
Design Model
A representation of the structure of a software solution by a class diagram; it represents classes, their associations and constraints and their responsibilities in terms of operations.
43
Development Process
A set of rules that define how a software development project should be carried out. It incorporates a life cycle and involves a number of methods and procedures.
44
UML Diagram
In UML, a diagram is a graphical presentation of a collection of model elements.
45
Disclosure
Attack of private information or the unauthorised release of information.
46
Discoverable
The property of a service in a service oriented architecture that allows the architecture to identify services on behalf of a consumer. (See also service and service-oriented architecture.)
47
Domain
An area or field of knowledge characterised by a set of concepts and terminology that is understood by practioners in that area.
48
Domain Analysis
A form of requirements elicitation in which existing systems in the domain are examined and domainexperts are consulted.
49
Domain Modelling
Modelling what already exists.
50
Dynamic Model
Describes the behaviour of a software system over time.
51
DSDM
Dynamic Systems Development Method
An agile software development method.
52
Elaboration
In UP, phase most analysis and design occur.
53
Element
In UML, an element is an atomic constituent of a model.
54
Encapsulation
Hiding from the clients of a class the details of how the class is implemented. In other words, it is the process of hiding (making private) all the methods and data fields of a class used in the implementation of the public methods (or interface) of the class.
55
Engineering
A systematic approach to efficiently developing products which are fit for purpose, based on a body of knowledge.
56
Enterprise Beans
Another name for EJB components. They are server-side components, that is to say, they are distributed entities that provide remote services to clients distributed throughout the network.
57
EJB
Enterprise JavaBeans
A component technology, based on the Java programming language. It defines a standard that allows organisations to build their own components or acquire components from third-party vendors.
58
Exploration
A move of the planning game that finds out new things that can be done.
59
Extension
A form of inheritance in which the child class adds functionality to the parent class but does not change any inherited behaviour.
60
Extension Points
A place in the main success scenario of a use case where the condition that triggers a subsidiary use case is tested.
61
Fit Criteria
A quantification or a measurement of a requirement expressed in a way that allows you to assess whether or not the final product satisfies, or fits, that requirement.
62
Fork
In activity diagrams, a fork node splits control into multiple parallel flows.
63
Functional (or Logical) View
In a software architecture it describes the system’s main functional elements, their responsibilities, interfaces and primary interactions. A functional view is the cornerstone of most architectural descriptions.
64
Functional Requirement
a specified action that a system has to perform
65
Further Analysis
The adding of additional detail to a system specification. In particular, system operations and model constraints.
66
Glossary
A list of terms or words relating to a particular domain or text, along with an explanation of each term.
67
Guard
A condition that must be satisfied in order to enable an associated transition to fire within a state machine or activity diagram.
68
Guillements
Angled brackets (« …») used in UML to show a stereotype. They have other more general uses.
69
Heroic Programming
A form of software development where a single person attempts to have in mind everything concerning a given problem and its eventual solution.
70
Human Factors
The discipline that deals with the relationship between people and technology.
71
Implementation
The process of building a coherent set of instructions for a computer, that will cause it to exhibit a behaviour specified by the artefacts which are normally devised during design. It is one of the four basic technical activities within a software development process (see also analysis, design and testing).
72
Inception
In UP, phase when the initial planning of development occurs.
73
Inclusion
A relationship between two or more use cases, when there is an overlapping area of functionality – that is, a common task – that can be factored out as a distinct use case. The new use case can then be used by each of the original use cases, so avoiding duplication.
74
Increment
The difference between two releases of a (software) deliverable at the end of successive iterations.
75
Incremental Development
This development approach partitions the system into a number of independent or reasonably independent ‘chunks’. The process begins by developing one chunk – the core – and adding successive increments to it over time. A significant point about this method is that the core is a functioning item of software that meets some of the requirements. As each increment is added, the resulting software is still functional.
76
Initial Problem Statement
An initial statement of a problem from which development proceeds. In order to draw up detailed requirements it will usually be necessary to clarify and expand on the information in the initial problem statement during requirements elicitation. (See also requirements elicitation.)
77
Integration
An activity in which individual software modules or components are combined into an executable whole.
78
Integrity
in general, the property that data has not been subject to unauthorised change. In particular, a software quality factor affecting product operation requirements which determines the extent to which access to data by unauthorised persons can be controlled, that is, how well the data is secured.
79
Interatction Diagram
A UML diagram that shows the sequencing of messages in an interaction. (See also sequence diagram and communication diagram.)
80
Interface
In general, this refers to the operations (methods), including their syntax and semantics, that a software system/subsystem/module provides to the clients of the system. In the object-oriented approach, the public operations associated with an object are referred to as its interface, or its interface operations. In Java, an interface is a construct similar to a class, which provides a specification (in the form of method headings but no implementation) of the methods for which classes implementing the interface must provide implementations.
81
Interoperability
A software quality factor affecting product transition requirements which determines the effort required to couple one system to another, that is, how easy it is to interface the system with another, should the customer require it.
82
Iteration
A distinct sequence of activities within a life cycle that may be repeated. Within a development process, the result is a (software) deliverable that conforms to certain criteria.
83
Iteration Planning Game
A planning game for an iteration, played even more frequently, on tasks instead of stories; the players are the programmers.
84
Iterative and Incremental Development
This development approach starts with a subset of the requirements and incrementally grows the system with further increments. Each increment is developed over several iterations; an iteration is a complete small project, with a short timeframe, consisting of analysis, design, implementation, testing and integration, and results in a partially working system.
85
Iterative Development
This development approach continuously repeats a set of activities improving the outputs each time at the feedback received from a previous iteration.
86
Join
In activity diagrams, a join node synchronises multiple parallel flows.
87
Layer
A logical partitioning of a system.
88
Layered Architecture
An architecture organised using a Layers pattern.
89
Layers Pattern
This organises the large-scale functional structure of a system into discrete layers of distinct, related responsibilities, with a clear separation of concerns between the layers.
90
Legacy System
An old software system that is still required because it meets some useful purpose to an organisation. It is not considered to be replaceable and so it is maintained, usually on a restricted budget.
91
Legal Requirement
A non-functional requirement about laws and standards that apply to the product.
92
Life Cycle
The sequence in which a number of different activities are carried out to define an overall process for the development of a software system.
93
Look and Feel Requirement
A non-functional requirement about the product’s appearance.
94
Maintainability
This is a software quality factor affecting maintainability and portability requirements, which determines the effort required to understand, locate and fix errors in a system, that is, how easily bugs can be found and fixed.
95
Maintainability and Portability Requirement
A non-functional requirement about expected changes to a system and allowed time to make them.
96
Maintenance
An activity in which the artefacts or products of a software development process are changed. It includes all changes made to a software system after it has been released.
97
Malleability
Characteristic of software as being easy to change. Malleability creates a constant pressure for software to be changed rather than be replaced. Every change that is made to the software introduces the possibility of new errors.
98
Merge Node
In an activity diagram, this is a node that brings together multiple alternative flows; represented by a diamond shape; a merge node has a single outgoing transition.
99
Method
In object-oriented terminology, it is an operation that manipulates an object in some way.
In Java, a method is a member of a class and has a method heading (which incorporates its signature) and a method body.
In software development, it is a collection of integrated techniques, with their associated notations and rules, that takes a set of predefined inputs and converts them to a set of predefined outputs.
100
Model
A simplification of reality, created in order to understand an aspect or viewpoint of the system being created. In the MVC, the model the component that does the processing.
101
Modelling
A way of thinking about things and ideas in the real world. A model is a way of expressing a particular view of an identifiable system.
102
Modelling Language
A way of expressing the various models produced during the development process. A modelling language defines a collection of model elements, which are roughly equivalent to the utterances in a spoken language. (A model is made up of model elements, as sentences are made up of words.) UML is a modelling language.
103
Modification
Loss of Integrity
Attack consisting of the unauthorised modification of data.
104
Modularity
The division of a software system into separately named and addressable components, called modules, that are integrated to meet the requirements. Modularity is a basic attribute of software that allows the partition of a set of requirements into a number of intellectually manageable subsets.
105
Module
A program unit (or component) that is used exclusively through an external interface. It is important for enabling a system to be comprehended at any required level of detail. A software system is a collection of modules.
106
MoSCoW
Must have, Should have, Could have, Wont have
A scheme in DSDM classifying requirments
107
Non-Fuctional Requirment
A quality that a system must have.
108
OCL
Object Constraint Language
109
Operational and Environmental Requirement
A non-functional requirement about how the environment on which the product will have to work (under water, for example), and what considerations must be made for this environment.
110
Oracle
The criteria in a test case that helps define whether the test is passed.
111
Partition
The decomposition of a problem into a number of subproblems that are independent of each other.
112
Performance Requirement
A non-functional requirement about how fast, how safe, how accurate, how available and how reliable the product must be.
113
Plan-Driven Development
Term used to distinguish traditional, more prescriptive approaches to software development from agile development approaches.
114
Planning
The first stage of a formal technical review.
115
Planning Game
An XP practice with two participants, the business and the development. This game takes place not only at the beginning of the project but at regular intervals (say every three weeks) to determine the priorities and work for the next release and to define a plan. It is played with story cards. (See iteration planning game.)
116
Portability
A software quality factor affecting product transition requirements which determines the effort required to transfer the system from one hardware platform and/or software environment to another, that is, how easily the system can be used on another machine should the customer change their platform or should other customers require it.
117
Postcondition
A constraint that must be true at the completion of an operation, or use case.
118
Precondition
A constraint that must be true when an operation is invoked, or when a use case is carried out.
119
Procedure
In general, a procedure is a prescribed set of steps for carrying out a task. In programming, it refers to a block of code that carries out a specified programming task and may or may not have input and output parameters. In object-oriented systems, methods are used to implement procedures.
120
Process
In program execution, a process is a dynamic (abstract) entity that executes a program on a processor. It is associated with resources such as a main memory and files. In this context, processes are also sometimes referred to as tasks.
In software development, a process is a set of activities or operations that takes one or more inputs, such as a design document, and results in one or more products, such as a software module and its test cases.
121
Process Improvement
The idea that an organisation should learn from difficulties encountered with their existing processes, and improve as a result.
122
Process View
In a system architecture, this view addresses concurrent aspects of the system at run-time, including all system processes and system start-up and shut-down.
123
Product Backlog
An artefact in Scrum (an agile method) that consists of an ordered structured list of what needs to be done to a system.
124
Project Management
The activity concerned with ensuring that a software project is completed within the estimated time. It involves determining the work involved, assigning work units to people or teams for periods of time, and giving a work plan for the project.
125
Project Plan
A plan breaking down the development of a system into stages and showing how much resource is required at each stage.
126
Prototype
A simplified software system that is a subset of the eventual product.
127
Provider
In SOA the platform on which a service is implemented.
128
Quality Management
An activity that takes place throughout the software development process to ensure the quality of the final product.
129
Registry
A mechanism that allows clients to find services.
130
Release
A configuration version delivered on completion of the project for use by the customer.
131
Reliability
A software quality factor affecting product operation requirements which determines the likelihood with which a system can be expected to perform its intended function, that is, how well the software does what it is supposed to do.
132
Repudiation
Attack consisting of (false) claim by legitimate user that a message was not sent or received.
133
Requirement
A desired feature, property or behaviour of a software system.
134
Requirement Analysis
An activity undertaken to decide what needs to be done to solve the problem that has been articulated during requirements elicitation. The result is a deliverable that forms the basis for a solution to be implemented. It is expressed in technical terms that are understandable to the developers.
135
Requirements Documentation
An activity undertaken to record agreed requirements.
136
Requirements Elicitation
An activity undertaken to discover, identify, review, articulate and understand the users’ needs and constraints on the software and its development. The result is a clear statement of the problem to be addressed.
137
Requirements Engineering
An activity in the process of developing software that aims to elicit and specify the requirements of the client(s)/user(s) in a form that can be used in the design of the software and in assessing its quality once it is built. It can be divided into two main activities: requirements elicitation and requirements analysis.
138
Requirements Negotiation
An activity undertaken to agree requirements.
139
Requirements Pattern
A description of knowledge used in the elicitation of requirements.
140
Requirements Specification
A detailed description of the requirements for a system.
141
Requirements Validation
A careful check of a requirements document, usually following a checklist.
142
Review
A software inspection meeting to confirm and list major defects, and to determine who will be responsible for addressing each defect.
143
Risk Managment
Analysis of risks in a development process and determination of steps to reduce them.
144
Role
The behaviour of an entity participating in a particular context. It may also refer to the behaviour of people in a domain.
145
Scenario
A specific sequence of actions that illustrates how a task can be performed. It is also a textual description of a specific instance of a use case or interaction with a user interface.
146
Scrum
An agile software development method.
147
Security
A term used in connection with controlling access to the data stored in computers and in connection with the availability of mechanisms that control or protect programs and data.
148
Security Requirement
A non-functional requirement concerned with aspects of a product such as security and confidentiality.
149
Service
A unit of reuse corresponding to a piece of functionality, described in a standard language, with published interfaces through which the service execution can be requested.
An abstract description of some unit of business functionality, usually described in terms that are meaningful from both a business and a technical perspective. (See also service-oriented architecture.)
150
Service Description
Specifies how a consumer can interact with a service.
151
Size (of Software)
This can be measured in terms of lines of code, number of symbols, size of source or object files etc.
152
Socio-Technical Systems
A system seen as a whole, including the software, the hardware where it is installed and running, and the wider context that involves other technical components, but also people, organisations and other social structures.
153
Software Architecture
‘… the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.’ (Bass, Clements and Kazman, 2012.)
154
Software Component
In the context of testing, the minimal software item for which a separate specification is available. In the context of reuse, usually a routine, a class (consisting of a collection of routines), or a collection of classes (a package), which has a specification (including interfaces) and a list of its underlying principles and concepts, as well as quality information such as levels of proof and testing.
155
Software Development
The process whose end product is a software product.
156
Software Quality
At a general level, this defines the extent to which the customer is satisfied with the software product delivered at the end of the development process. At a more detailed level, it involves conformance to explicitly stated requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software.
157
Software System
A general term referring to the end-product of software development. It embraces both application software and system software.
158
Sprint
In Scrum, a timeboxed period of to a maximum of a month where useable software is delivered.
159
Stakeholder
An individual and/or an organisation affected by the success or failure of a software system.
160
Static Model
A model that describes structure rather than behaviour. See structural model.
161
Static Modelling
Modelling of structure as opposed to behaviour.
162
Steering
A move of the planning game that updates the plan based on reality.
163
An extension mechanism in UML; it allows the creation of a new category of modelling element.
Stereotype
164
Supplier
In software development, the term refers to the person (or company) who develops a piece of software as a package.
In programming, the term often refers to the method/class/object that is used by methods of another class/object (the client).
In network programming, the term refers to a program/process running on one computer that provides services to another program running (usually) on another computer.
165
Swimlane
A means of indicating a role's responsibilities in an activity diagram. Swimlanes show the concurrent activities of actors as separate partitions.
166
Synchroisation Bar
A means of describing the coordination of activities. Once all the activities leading to the synchronisation bar have completed, the transitions leaving it will be fired. Thus, it is a point where the flow of control may change. A synchronisation bar is used to identify the points at which concurrent threads begin (a fork) or end (a join).
167
System
An assembly of components that are connected in an organised way to perform some activity, that is, they behave dynamically.
168
System Boundary
A conceptual division between the system to be studied and ‘everything else’.
169
System Operation
An operation executed by a software system as a response to an external event.
170
System Requirement
‘…are a more detailed description of the functionality to be provided.’ (Somerville, 2011.)
171
Task
A single path of execution through a program, dynamic model or other representation of control flow such as an activity diagram. In general, it is a piece of work to be done by someone, such as an actor involved in a use case. It is also used as a synonym for process.
172
Techical Solution Requirements
These relate to functionality that is needed purely because of the chosen technology.
173
Testability
A software quality factor affecting product revision requirements which determines the effort required to test a system to ensure that it performs its intended function, i.e. how easily the system can be tested to show that the customer’s requirements have been met.
174
Testing
The process of determining if an artefact meets a given specification. It is one of the four basic technical activities within a software development process (see also analysis, design and implementation). In practice, it is the use of techniques for the validation or verification of products or the processes by which they are made.
175
Timeboxed
Within a short time frame.
176
Timeboxing
Allocating short fixed periods – for example, three to four weeks – to each iteration.
177
Tool
Software used to support the software development process.
178
Traceability
The ability to trace the history of each requirement from problem description through conceptual and specification models to the implementation and deployment models in order to reconstruct the significant events that led to the final operational software system. The ability to record information that will allow any investigation to reconstruct events, changes and reasons for change.
179
Trade
‘A job, especially needing a special skill with the hands: Being a printer is a trade; being a lawyer is a profession.’ (Longman Dictionary of Contemporary English, 1987.)
180
Training
A process which assists in enabling new users to use a system effectively. It may include manuals, self-study modules or face-to-face lecturing.
181
Transition
In state machines or activity diagram, the movement between states or activities triggered by an event. In UP, phase when the final product is tested and deployed.
182
UML
Unified Modeling Langauage
A language for visualising, specifying, constructing and documenting the artefacts of a software-intensive system. (See also modelling language.)
183
UP
Unified Process
A popular iterative and incremental process for building enterprise systems based on an object-oriented approach. It consists of four phases: inception, elaboration, construction and transition.
184
Usability
The effectiveness, efficiency and satisfaction with which users can achieve tasks in a particular environment. High usability means a system is easy to learn and remember; efficient, visually pleasing and fun to use; and quick to recover from errors. Also, usability is a software quality factoraffecting product operation requirements which determines the effort required to learn about, to operate, to prepare input for, and to interpret the output of a system, that is, how easy the system is to use.
185
Usability Requirement
A non-functional requirement about the product’s ease of use or other usability considerations.
186
Use Case
A description, of a piece of functionality that a system performs to yield an observable result of some value to an actor. (See also task.)
187
Use Case Diagram
A diagram that shows a set of use cases and actors and their associations.
188
User
A person who uses the software system on a day-to-day basis.
189
User-Centered Design
During analysis and design, a way of taking into account the different perspectives of different userswhen looking at the tasks that they perform; typically found in techniques used for requirements engineering.
190
User Requirements
‘… abstract statements of the software requirements for the customer and end-user of the system.’ (Somerville, 2004.)
191
User Story
A story written by an intended user of a system; it describes some functionality that is of value to the person(s) writing the story. It represents a user’s expectation of the system.
192
Validation
The process of checking that a software system is consistent with the customer’s requirements; that is, the developer is building the ‘right’ product. (See also verification.)
193
Variables
In Java, a data field that holds a particular type of value or refers to a particular type of object. Unlike a data field declared as static, the value associated with a variable data field may be changed. (See also class variable and instance variable.)
194
Variant
In a configuration management system, two configuration items which are essentially the same but differ in some well defined sense are called variants. Variants are distinguished by having different descriptive names, and also have descriptions characterising them. Variants themselves undergo revisions and thus have versions.
195
Verification
A process of ensuring that the design of a system corresponds to its specification, and that the system is correctly coded according to its design; that is, all the different system descriptions are consistent and complete with respect to each other. If validation is about building the ‘right’ product, then verification is about the product being built ‘right’.
196
Version
An ‘instance’ of a configuration item. Also referred to as a revision.
197
Viewpoint
A perspective on a system from the point of view of a particular person or group of people.
198
Volere Template
This is a template for a document that collates all the requirements of a system, together with other issues that may affect those requirements. The template provides a sort of container, in which the information can be organised systematically.
199
Waterfall Model
A particular life cycle that uses the analysis, design, implementation and testing activities in a simple sequence with little or no iteration. Some versions append the maintenance activity.
200
Workflow
The steps that people go through when doing their jobs. A workflow may contain a number of activities that must be coordinated and arranged in a specified order to achieve a goal. A workflow can be used to represent the flow of activities that takes place in a business process.
201
XP
Extreme Programming
