Home  |  News Bites  |  Product News  |  Downloads  |  Links  |  Email  |  Contact
            DentalXS

Access Portal for Dental Informatics, Computerized Dentistry and Dental CAD/CAM

 

 

Glossary 

 

This glossary is an aid in improving communication between researchers, developers and users of computerized dental systems 

   Glossary                                                 
 
 

abstract class

A class that can only be instantiated in connection with an instance of one of its descendant subclasses.

abstract component

The design and partial implementation of a component that must be completed to create a software component. Such a component is also a white-box component.

abstraction

The act of identifying the essential characteristics af a thing that distinguishes it from all other kinds of things.

abutment

The connecting element between fixtures and dental crowns which penetrates the soft tissue between the jawbone and the oral cavity.

actor

A person playing a specific role, a software system, or a hardware device that interacts with a system to achieve a useful goal. Also called a user role.

acceptance criteria

A priotized list of criteria that the final product(s) must meet before the customer will accept them; a measurable definition of what must be done for the final product to be acceptable to the customer. They should be defined as part of the Project Brief and agreed between the customer and supplier no later then the project initiation stage. They should be documented in the Project Initiation Document (PID).

activity network

A flow diagram showing the activities of a plan and their dependencies. The network shows each activity’s duration, earliest start and finish times, latest start and finish times and float. Also known as "planning network". See also Critical Path.

aesthetics

In this context: advantageous in terms of appearance, attractive.

alternate flow of events

Covers optional or exceptional behavior as well as variations of the normal behavior ("detours" from the basic flow of events).

alveolar bone

The bone of the maxillae or mandible that surrounds and supports the teeth.

analyst

Development team member responsible for gathering and recording the business rules of the use cases.

application

The union of all the use cases in the requirements; excludes the user interface. Also refers to the implementation of the use cases in the control class.

archetype

A rule, or rules, detailing how to transform a general xUML model element into text.

architectural description language

A language for describing the structure of a component-based system into its relevant components and connectors.

architectural driver

A functional, quality, or business requirement that greatly influences the composition of the software component infrastructure for an application.

architecture

The fundamental organisation of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its evolution and design.

articulation

The contact relationship of the maxillary and mandibular teeth when moving into and away from centric occlusion.

artifact

A product of a creative activity or a manufacturing step.

aspect

A fragment of code, typically a statement, method, or template, perhaps parameterized, that will be composed with base code and other aspects into a complete method, class, or component to create complete components or products.

association class

A class that models an association.

association

The abstraction of a relationship that holds systematically between objects.

attribute

A real-world characteristic, property, or element of information belonging to an entity. An entity is (statically) described by its attributes. In an object database, instance variables may be considered attributes of objects. In programming language, values associated with a type definition are attributes.

baseline

A snapshot; a position or situation that is recorded. Although the position may be updated later, the baselined remains unchanged and available as a reminder of the original state and as a comparison against the current position. Products that have passed their quality checks and are approved are baseline products. Anything "baselined" should be under version control in configuration management and "frozen", i.e. no changes to that version are allowed.

benefits

The positive outcomes , quantified or unquantified, that a project is being undertaken to deliver, and that justify the investment

benefits realisation

The practice of ensuring that the outcome of a project produces the projected benefits claimed in the Business Case.

Bennett movement

The bodily lateral movement or lateral shift of the mandible resulting from the movement of the condyles along the lateral inclines of the mandibular fossae in lateral jaw movements.

bespoke

A term used to describe a custom-made product or process. Applies to applications as well as components.

biocompatibility

Material which does not have a harmful effect on biological tissue. BioZyram (Zirconia) is an example of a biocompatible ceramic.

Bonwill triangle

An equilateral triangle with 4 inch sides, bounded by lines from the contact points of the lower central incisors or by the medial line of the residual ridge of the mandible, to the condyle on either side, and from one condyle to the other.

bridge

A class containing a set of bridge operations for a single required interface.

bridge operation

A realization of a required operation that uses one or more provided operations of one or more domains.

browser

A basic tool included in most repository-based development environments, allowing the user to easily and graphically "navigate" the links connecting objects in the structure. The browser may also act as a repository editor, allowing the creation, deletion, relocation, and duplication of objects or links.

business case

Information that describes the justification for setting up and continuing an OGP project. It provides the reasons (and questions "Why?") for the project. It is updated

at key points throughout the project.

business model

A model of all aspects of the system, irrespective of whether or not we intend to

automate them.

business object

An object with no application logic: this is the surrogate of the persistent business data.

business rule

A policy, guideline, standard, or regulation that defines or constraints some aspect

of business.

change authority

A Group to which the Project Board may delegate responsibility for the consideration of requests for change. The change authority is given a budget and can approve changes within that budget.

change budget

 

The money allocated to the change authority to be spent on authorized requests for change.

change control

 

The procedure to ensure that the processing of all Project Issues is controlled, including the submission, analysis and decision making. A team-level, time-driven review of progress, usually involving a meeting.

checkpoint

A progress report of the information gathered at a checkpoint meeting, which is given by a team to the Project manager and provides reporting data as defined in the Work Package.

class

A model summarizing the communication between classes within a domain.

class collaboration model

Graphical view of objects, their attributes, and associations. Created during analysis and usually refined during design. This is the object-oriented version of the data model.

class design

 

class diagram

A declarative diagram showing classes, their attributes, operations and relationships.

class library

 

A collection of classes that implement the basic functionality of a certain application domain or service domain, and can be used as a foundation to build more complex object-oriented software (example: a graphical user interface class library). Class libraries are a major component of a software reuse policy. Class libraries can be generated internally by an organisation as a means to effect internal reuse across projects; or they can be offered as commercial, off-the-shelf products.

client

The person for whom the software system is being developed. The individual or group of individuals that define the requirements and sign off on the business rules.

collaboration diagram

An interaction diagram emphasizing patterns of interaction and closeness of collaboration.

communication plan

Part of the Project Initiation Plan (PID) describing how the project’s stakeholders and interested parties will be kept informed during the project.

complaint

Means any written, electronic, or oral communication that alleges deficiencies related to the identity, quality, durability, reliability, safety, effectiveness, or performance of a device after it is released for distribution.

component

Means any raw material, substance, piece, part, software, firmware, labeling, or assembly which is intended to be included as part of the finished, packaged, and

labeled device.

composition

The combination of two or more software components yielding a new component behavior at a different level of abstraction. The characteristics of the new component behavior are determined by the componets being combined and by the way they are combined.

concession

An Off-Specification that is accepted by the Project Board without corrective action.

configuration audit

 

A comparison of the latest version number and status of all products shown in the configuration library records against the information held by the product authors.

configuration management

 

A discipline, normally supported by a software tool (Team Coherence), that gives management precise control over its assets (for example the products of a project), covering planning, identification, control, status accounting and verification of the products. Permits developers to work in parallel, merge later. Confusion between versions is prevented.

constraint

 

UML term for a rule or relationship that cannot be recorded as part of the basic class diagram. OODP term for an invariant, or method precondition.

contingency budget

The amount of money required to implement a contingency plan. If the Project Board approved a contingency plan, it would normally set aside a contingency budget, which would be called upon if the contingency budget, which would only be called upon if the contingency plan had to be implemented.

 

contingency plan

A plan that provides an outline of decisions and measures to be taken if defined circumstances, outside the control of an OGP project, should occur.

COTS

A COTS product is a product: sold, leased, or licensed to the general public offered by a vendor trying to profit from it and supported and evolved by the vendor, who retains the intellectual property rights available in multiple, identical copies used without modification of the internals.

critical path

This is the line connecting the start of a planning network with the final activity in that network through those activities with the smallest float. Often this is a line through which any delay will delay the time of the entire network.

cusp angle

The angle made by the slopes of a cusp with a perpendicular line bisecting the cusp, measured mesiodistally or buccolingually.

cusp height

The shortest distance between the tip of a cusp and its base plane.

cusp plane

 

customer

 

A project stakeholder who requests, pays for, selects, specifies, uses, or receives the output generated by a product. The user of the system may or may not be the same person as the client. Often, the customer is the same person that the client considers a customer.

control number

Means any distinctive symbol, such as a distinctive combination of letters or numbers, or both, from which the history of the manufacturing, packaging, labeling, and distribution of a unit, lot, or batch of finished devices can be determined.

data model

Collection of entities and their attributes used to represent a relational data base. The non-object-oriented equivalent of the class diagram.

deliverable

An item that the project has to create as part of the requirements. It may be part of the final outcome or an intermediate element on which one or more subsequent deliverables are dependent. According to the type of project, another name for a deliverable is "product".

dental bridge

A permanent prosthetic structure which only imposes a load on the wearer's teeth. Can also be performed using attachments and support on implants.

dental coping

In the Cyrtina® technique, the industrially-produced inner core of a dental crown made of ceramic or titanium. The dental technician applies a layer of porcelain to the outside of the dental coping to match the patient's other teeth.

dental crown

That part of the tooth which is normally visible above the gum.

design history file (DHF)

Means a compilation of records which describes the design history of a finished device.

designers

Development team members that refine the analysis use case descriptions into design, often using a sequence diagram to represent the messaging visually.

design input

Means the physical and performance requirements of a device that are used as a basis for device design.

design output

Means the results of a design effort at each design phase and at the end of the total design effort. The finished design output is the basis for the device master record. The total finished design output consists of the device, its packaging and labeling, and the device master record.

design review

Design reviews are documented, comprehensive, and systematic examinations of a design to evaluate the adequacy of the design requirements, to evaluate the capability of the design to meet these requirements, and to identify problems.

development

The activities of requirements, analysis, design, and implementation. Excludes test and user interface development.

device history record (DHR)

Means a compilation of records containing the production history of a finished device.

device master record (DMR)

Means a compilation of records containing the procedures and specifications for a finished device.

dependency

A reliance that a project has on an external factor, event, or group outside its control.

DDL Data Definition Language.

A language used to specify the structure and organisation of a database (e.g., the contents of each record and type of each field).

dispatching

In an object-oriented system, the routing of a request for execution of a method to the appropriate implementation of that method, which depends on inheritance relationships and the possible redefinition of methods within a class hierarchy.

domain

A separate real, hypothetical or abstract world inhabited by a distinct set of classes that behave according to the rules and policies characteristic of that domain.

domain chart

Actually a UML class diagram, showing domains, as UML packages, and their dependencies.

embedded systems

Embedded systems are dedicated to specific tasks, whereas PCs are generic computing platforms. They are supported by a wide array of processors, are cost sensitive, and have real-time constraints.

embedded microprocessor

An embedded microprocessor is a dedicated microprocessor. It is programmed to perform only one, or perhaps, a few tasks (opposite: general-purpose processor, such as Pentium).

end project report

A report given by the Project Manager to the Project Board, that confirms the hand-over of all products and provides an updated Business Case and an assessment of how well the project has done against its Project Initiation Document (PID).

end stage assessment

The review by the Project Manager to the Project Board of the End Stage Report to decide whether to approve the next Stage Plan (unless the last stage has now been completed). According to the size and criticality of the project, the review may be formal or informal. The approval to proceed should be documented as an important management product.

end stage report

A report given by the Project Manager to the Project Board at the end of each management stage of the project. This provides information about the project performance during the stage and the project status at stage end.

entity

An item in the business domain about which data will be collected and stored.

entry action

The sequence of processing which takes place on entry to a given state.

establish

Means define, document (in writing or electronically), and implement.

event

A trigger or stimulus that takes place in a system's environment that leads to a system response, such as behaviour or a change in state.

evolutionary prototype

A fully functional prototype created as a skeleton or an initial increment of the final product, which is fleshed out and extended incrementally as requirements become clear and ready for implementation.

exception

A situation where it can be forecast that there will be a deviation beyond the tolerance levels agreed between Project Manager and Project Board (or between Project Board and corporate or programme management, or between a Team Manager and the Project Manager).

exception assessment

This is a meeting of the Project Board to approve (or reject) an Exception Plan.

exception plan

This is a plan that often follows an Exception Report. For a Stage Plan exception, it covers the period from the present to the end of the current stage. If the exception were at a project level, the Project Plan would be replaced.

extreme programming

 

An "agile" software development methodology characterized by face-to-face collaboration between developers and on site representative, limited documentation of requirements in the form of "user stories", and rapid and frequent delivery of small increments of useful functionality.

feature

A set of logically related functional requirements that provides a capability to the user and enables the satisfaction of a business objective.

feasibility study

A feasibility study is an early study of a problem to assess if a solution is feasible. The study will normally scope the problem, identify and explore a number of solutions and make a recommendation on what action to take. Part of the work in developing options is to calculate an outline Business Case for each as one aspect of comparison.

final state vertex

The final pseudostate in which an object is deleted.

finished device

Means any device or accessory to any device that is suitable for use or capable of functioning, whether or not it is packaged, labeled, or sterilized.

 

follow-on action recommendations

A report that can be used as input to the process of creating a Business Case/Project Mandate for any follow-on OGP project and for recording any follow-on instructions covering incomplete products or outstanding issues. It also sets out proposals for post-project review of the project’s products.

Gantt chart

This is a diagram.

gold plating

Unnecessary or excessively complex functionality that is specified or built into a product.

horizontal prototype

A partial or possible implementation of a user interface for a software system. Used to evaluate usability and to assess the completeness and correctness of requirements. Also called a behavioral prototype or a mock-up.

identifier

A set of one or more attributes whose values uniquely distinguish each object of a class.

IEEE

The Institute of Electrical and Electronics Engineers. A professional society that maintains a set of standards for managing and executing software and systems engineering projects.

implant

From the Latin implantere – to implant. A prosthesis inserted during surgery.

implementers

The programming language coders that do some very low level design and develop the classes and their methods.

includes relationship

A construct in which several steps that recur in multiple use cases are factored out into a separate sub-use case, which the higher-level (or "calling") use cases then invoke when needed.

inheritance

A relationship among classes, wherein one class (the "subclass" or "child class" shares the structure and behavior defined in another class (the "superclass" or "parent class"). Additions and redefinitions can occur in the subclass structure and behavior.

interaction

An action between two or more software elements.

interface

An abstraction of the behavior of a component that consists of a subset of the interactions of that component together with a set of constraints describing when they may occur. The interface describes the behavior of a component that is obtained by considering only the interactions of that interface and by hiding all other interactions.

invariant

A constraint that must always be true. It is the responsibility of the methods that change the attributes participating in the constraint to guarantee that it remains true.

initial state vertex

Indicates the point that an object of a class that has a state machine comes into being and starts operating.

issue

A risk that has become a reality.

iteration plan

A time-sequenced set of activities and tasks that includes assigned resources and task dependencies for the iteration; a fine-grained plan.

link

An instance of an association.

lot or batch

Means one or more components or finished devices that consist of a single type, model, class, size, composition, or software version that are manufactured under essentially the same conditions and that are intended to have uniform characteristics and quality within specific limits.

manager with executive responsibility

Means those senior employees of a manufacturer who have the authority to establish or make changes to the manufacturer’s quality policy and quality system.

manufacturer

Means any person who designs, manufactures, fabricates, assembles, or processes a finished device. Manufacturer includes but is not limited to those who perform the functions of contract sterilization, installation, relabeling, remanufacturing, repacking, or specification development, and initial distributor(s) of foreign entities performing these functions.

manufacturing material

Means any material or substance used in or used to facilitate the manufacturing process, a concomitant constituent, or a byproduct constituent produced during the manufacturing process, which is present in or on the finished device as a residue or impurity not by design or intent of the manufacturer.

mechanism

Code elements that are not subject to translation rules at code generation time.

metaclass

A class whose instances are classes in a different model.

metamodel

A model of the elements of a language , e.g. a UML model of UML.

method

An implementation of an operation.

method parameter

The name and type of an input to the method, and the identifier by which the value passed to the method will be known within the body of the method.

method pre-condition

A constraint associated with a method. It defines something that must be true before the method is invoked. It is the responsibility of the one who invokes the method with a pre-condition to make sure that the method pre-condition is true before sending the message that will run that method.

Molar

Back tooth, grinder.

Multiplicity

The multiplicity on an association end indicates how many objects participate in each association.

Nonconformity

Means the nonfulfillment of a specified requirement.

normal course

The default sequence of steps in a use case, which leads to satisfying the use case's postconditions and letting the user achieve his goal. Also known as the basic course, main course, normal sequence, flow of events, main success scenario, and happy path. The basic flow of events that covers what "normally" happens when the use case is performed.

Object

A specific instance of a class for which a set of data attributes and a list of operations that can be performed on those attributes can be collected. For example, "Mary Jones" is a specific instance of the class "Customer".

object attribute

See attribute.

operation

An action that can be invoked via a parameterized interface.

optical impression system

An optical impression system for CAD/CAM of dental restorations is a device used to record the topographical characteristics of teeth, dental impressions, or stone models by analog or digital methods for use in the computer aided design and manufacturing of dental restorative prosthetic devices. Such systems may consists of a camera, scanner, or equivalent type of sensor and a computer with software.

orestes software development process (OSDP)

A comprehensive, flexible software development framework that embodies an iterative approach and other best practices.

oral surgery

That part of dentistry comprising the diagnosis and surgical treatment of diseases of the oral cavity and jaws.

osseointegration

A direct structural and functional connection between well-organized, living bone and a surface by a force-absorbent implant.

pattern

A generalized solution to a commonly occurring problem.

periodontology

The study of everything relating to the neck of a tooth and the surrounding tissues and their diseases, such as periodontitis.

phase plan

 

A high-level, coarse-grained view of the project, developed during the Inception phase. It shows the total number of planned iterations across the four ORESTES SOFTWARE DEVELOPMENT PROCESS (OSDP: PRO 430) phases.

platform

A technology, or set of related technologies, e.g. CORBA, J2EE, XML, C++.

polymorphic signal

A signal that is directed to exactly one class, and is available to all subclasses of the class to which it is directed. 

postcondition

 

A condition that describes the state of a system after the use case is successfully completed.

precondition

A condition that must be satisfied or a state the system must be in before a use case may begin.

primary scenario

The most usual path that captures the normal behavior associated with the use case.

product

Means components, manufacturing materials, inprocess devices, finished devices, and returned devices.

prosthetics

Prosthesis = replacement for a lost body part. In this context; oral prosthetics – that part of dentistry which deals with problems relating to the replacement of teeth and/or jaws.

provided interface

 

The set of services a domain offers on behalf of a single terminator. A domain may have many provided interfaces-zero or one per terminator.

quality

Means the totality of features and characteristics that bear on the ability of a device to satisfy fitness-for-use, including safety and performance.

quality attribute

A kind of nonfunctional requirement that describes a quality or property of a system. Examples include usability, portability, maintainability, integrity, efficiency, reliability, and robustness. Quality attribute requirements describe the extent to which a software product demonstrates desired characteristics, not what the product does.

quality audit

Means a systematic, independent examination of a manufacturer’s quality system that is performed at defined intervals and at sufficient frequency to determine whether both quality system activities and the results of such activities comply with quality system procedures, that these procedures are implemented effectively, and that these procedures are suitable to achieve quality system objectives.

quality policy

Means the overall intentions and direction of an organisation with respect to quality, as established by management with executive responsibility.

quality system

Means the organisational structure, responsibilities, procedures, processes, and resources for implementing quality management.

required interface

The set of services associated with a single terminator that a domain will not realize itself, but which the domain requires to be realized by some other domain. A domain may have many required interfaces-zero or one per terminator.

requirement

An informal statement of a customer need or objective, or of a condition or capability that a product must posses to satisfy such a need or objective. A property that a product must have to provide value to a stakeholder. These are not the use case definitions developed during the requirements activity as a formal response to requirements.

requirement attribute

Descriptive information about a requirement that enriches its definition beyond the statement of intended functionality. Examples include origin, rationale, priority, owner, release number, and version number.

requirement management

The process of working with a defined set of product requirements throughout the product's development process and its operational life. Includes tracking requirements status, managing changes to requirements and versions of requirements specifications, and tracing individual requirements to other project phases and work products.

Rework

Means action taken on a nonconforming product so that it will fulfil the specified DMR requirements before it is released for distribution.

risk

An ongoing or upcoming concern that has a significant probability of adversely affecting the completion of major milestones and quality.

risk management plan

Details how to manage the risks associated with a project. Specifies risk management tasks that will be carried out, assigns responsibilities, an identifies additional resources required for the risk management activity. For smaller projects, this plan may be embedded within the Software Development plan

risk list

 

A list of known and open risks to the project, sorted in decreasing order of importance and associated with specific mitigation or contingency actions.

run time

Refers to all the components of a computer environment which are used during the execution as opposed to its construction of the actual software or system product

run-time binding

In an object-oriented programming system, the ability to dynamically change the method which is executed in response to a message, according to the current type of object to which the message, according to the current type of object to which the message is addressed (opposite: compile-time binding).

run-time environment

The run-time environment consists of all the software structures (not explicitly created by the programmer) that support program execution.

run-time library

The run-time library is a set of otherwise invisible support functions that simplify code generation. Example: On a machine that does not have hardware support for floating point operations, the compiler generates a call to an arithmetic routine in the run-time library for each floating-point operation.

scenario

One particular path through a use case.

scenario pre-condition

The final values of the business object attributes, that define when the scenario is in effect.

scenario post-condition

The final values of the business object attributes for a scenario, expressed in terms of the scenario pre-condition and, when necessary, use case inputs and additional business object attributes.

secondary scenario

This captures paths through a use case that deal with less usual behavior such as exception handling and error behavior.

secure product

 

A product that protects the confidality, integrity, and availability of the customers’ information, and the integrity and availability of processing resources, under control of the system’s owner or administrator.

security vulnerability

A flaw that makes it infeasible – even when using the product properly – to prevent an attacker from usurping privileges on the user’s system, regulating its operation, compromising data on it, or assuming unbranded trust.

sequence diagram

An interaction diagram showing the interaction between objects, emphasizing the time ordering of the interactions.

server

In a network of computer systems, a machine or process which is available to fulfil requests sent by other machines and processes for a specific function. Example: file server, database server, user interface server, print server, etc. Opposite of "client". 

signal

This represents an incident that causes a state transition; it is asynchronous in nature.

software development life cycle

A sequence of activities by which a software product is defined, designed, built, and verified.

software development plan

A comprehensive, composite artifact that gathers all information required to manage the project. It encloses a number of artifacts developed during the Inception phase and is maintained throughout the project.

software element

A sequence of abstract program statements that describe computations to be performed by a machine.

software requirement specification (SRS)

A collection of the functional and nonfunctional requirements for a software product.

specification

A specification is defined as "a document that states requirements." It may refer to or include drawings, patterns, or other relevant documents and usually indicates the means and the criteria whereby conformity with the requirement can be checked. There are many different kinds of written specifications, e.g., system requirements specification, software requirements specification (SRS), software design specification, software test specification, software integration specification, etc.

sponsor

Not a specific OGP role but often used to mean the major driving force of a project. May be the equivalent of Executive or corporate/programme management.

Stakeholder

A person, group, or organization that is actively involved in a project, is affected by its outcome, or can influence its outcome.

standard

An object or quality or measure serving as a basis to which others should conform, or by which the accuracy or quality of others is judged (by present-day-standards). This term includes proprietary vendor and producer standards as well as national and international standards produced by recognized standards bodies.

state

This represents a condition of thaw class subject to a defined set of rules, policies, regulations or physical laws.

statechart

This provides a graphical representation of the way in which each class responds to the signals.

stereotype

An extension mechanism that allows new UML elements to be created from existing ones.

supplier

The group or groups responsible for the supply of the project’s specialist products. 

system (product)

The combination of the application, the user interface, and, when appropriate, any hardware.

system requirement

A top-level requirement for a product that contains multiple sub-systems, which could be all-software or software and hardware.

team manager

 

A role that may be employed by the Project Manager or a specifically appointed alternative person to manage the work of project team members.

terminator

An abstraction of an entity external to a domain with which a domain interacts.

test

Those activities within the process that deliver test plans and test cases and that test the completed use cases.

testers

Those members of the development team responsible for writing the test plan, developing the test cases, and testing the use cases.

tolerance

The permissible deviation above and below a plan’s estimate of time and cost without escalating the deviation to the next level of management. Separate tolerance figures should be given for time and cost. There may also be tolerance levels for quality, scope, benefit and risk. Tolerance is applied at project, stage and team levels.

tracing (also traceability)

The process of defining logical links between one system element (use case, functional requirement, business rule, design component, code module, test case, and the like) and another.

transition

Specifies the state that an object will enter from a given state on receipt of a specific signal.

use case

A visual description of a set of logically related possible sequence of interactions between an actor and a system that results in an outcome that provides value to the actor. Can encompass multiple scenarios. A use case contains all alternate flows of events related to producing an "observable result of value."

use-case flows

Generic term for the use-case flow of events and the alternate flow of events.

use case definition

The use case, as defined during requirements, that identifies its inputs, outcomes, and outputs.

use case description

The use case, as developed during analysis, complete with all the business rules for each scenario.

use case design

 

The use case, as refined in design, showing all of the messages between objects that are required to correctly implement the use case description. This is the structure that will be the basis for the use case implementation.

use case diagram

An analysis model that identifies the actors who can interact with a system to accomplish valuable goals and the various use cases that each actor will perform.

use case outcome

One of several logical results of a use case, as defined by the client during requirements. The use case outcome may be refined into one or more use case scenarios during analysis.

use case parameter

The information required to run the use case, as defined by the client, including its name and type. The name is the identifier by which the input will be known within the body of the use case definition, description and design.

use case scenario

The logical result of a use case as defined by the client during analysis. Each scenario has a unique pre-condition and post-condition.

user

A customer who will interact with a system either directly (for example using outputs from the system but not generating those outputs personally). Also called end user.

user interface design

Activity within OODP where the physical layout (look and feel) of the user interface, in graphical form, is assembled to allow the client and/or user to see the visual access to the application.

user interface development

Activity within OODP where the user interface design is implemented and brought to realization in the target programming language.

validation

Establishing documentary evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specification and quality attributes. 

(1) Process validation means establishing by objective evidence that a process consistently produces a result or product meeting its specifications.

(2) Design validation means establishing by objective evidence that device specifications conform with user needs and intended use(s)

variable

Name by which objects are referred to in an object-oriented program. Variables can be objects or atomic values, like primitives. Every attribute is also a program variable.

verification

The process of evaluating a work product to determine whether it satisfies the specifications and conditions imposed on it at the beginning of the development phase during which it was created.

vertical prototype

A partial implementation of a software-containing system that slices through all layers of the architecture. Used to evaluate technical feasibility and performance.

visibility

The permissions associated with how a name may be seen and used by other model elements.

vision and scope document

A document that presents the business requirements for a new system, including a product vision statement and a project scope description.

waterfall development life cycle

A model of the software development process in which the various activities of requirements, design, coding, testing, and deployment are performed sequentially with little overlap or iteration.

work package

The set of information relevant to the creation of one or more products. It will contain the Product Description(s), details of any constraints on production such as time and cost, interfaces and confirmation of the agreement between the Project Manager and the person or Team Manager who is to implement the Work Package that the work can be done within the constraints.