Glossary

actor (instance): Someone or something, outside the system that interacts with the system. 1

actor class: Defines a set of actor instances, in which each actor instance plays the same role in relation to the system.; 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

AM: Agile Modelling. This is a modeling methodology. More at www.agilemodeling.com

analyst: Member of the project team who is responsible for eliciting and interpreting the stakeholder needs, and communicating those needs to the entire team. 1

anti-pattern: http://c2.com/cgi/wiki?AntiPatterns

architecture: The highest level concept of a system in its environment [IEEE]. The architecture of a software system (at a given point in time) is its organization or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces.; 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. Parts that interact through interfaces include classes, components and subsystems. 1

Artifact (or English Spelling Artefact): (1) A piece of information that (1) is produced, modified, or used by a process, (2) defines an area of responsibility, and (3) is subject to version control. An artifact can be a model, a model element, or a document. A document can enclose other documents.; A piece of information that is used or produced by a software development process. An artifact can be a model, a description, or software. Synonym: product. 1

ATAM: Architecture Tradeoff Analysis Method. SEI term.

BA: Short for Business Analyst. A role in software development, which requires the person to analyse the business and document or model it such that it may be authenticated and shared amongst the team for a common understanding.

Business Actor - class: A class that defines a set of business actor instances, where each instance plays the same role in the business.

Business Actor - instance: An entity (either person, system or thing) which interacts with the Business or Organisation.

Business Use Case - class: A Business Use Case Class defines a set of instances which each deliver an observable result which has value to the business actor.

Business Use Case - instance: A series of actions done by an organisation or business that produce an observable result which has value to the business actor.

change management: The activity of controlling and tracking changes to artifacts. See also scope management. 1

Class Model: A Model is a complete set of class diagrams and modeling objects that make up a meaningful set of pictures which describe what the author is trying to convey.

class: A description of a set of objects that share the same attributes, operations, methods, relationships, and semantics. A class may use a set of interfaces to specify collections of operations it provides to its environment. See interface.

class diagram: A diagram that shows a collection of declarative (static) model elements, such as classes, types, and their contents and relationships.

class hierarchy: The relationships among classes that share a single inheritance. All Java classes inherit from the Object class.

class library: A collection of classes.

class method: See method.

CMM: Capability Maturity Model - defined by the Software Engineering Institute (SEI) at Carnegie Mellon University. Describes the level of capability and maturity a software team could aim for and could be assessed against.

CMMI: Capability maturity Model Integration.

COTS: Commercially-off-the-shelf. Usually refers to software packages or systems implemented in a company.

DBA: Data-Base Administrator.

DFD: Data Flow Diagram.

design: 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. See analysis. 1

Discipline
: A discipline is a collection of related activities that are related to a major 'area of concern'. The disciplines in RUP include: Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, Environment. 1

Enterprise Architecture: ... the set of descriptive representations (i.e. models) that are relevant for describing an Enterprise such that it can be produced to management's requirements (quality) and maintained over the period of its useful life (changed) ²

FDD: Feature Driven Development.

Framework: 1. A structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed.; 2. An external work platform; a scaffold.; 3. A fundamental structure, as for a written work.; 4. A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality.

GRASP: An acronym for a type of pattern. Stands for General Responsibility Assignment Software Patterns.

Guideline
: A guideline is a document which helps specify practical information on techniques to help you perform certain tasks.

IDE: Integrated Development environment.

IT: Information Technology

Iteration: A distinct sequence of activities with a base-lined plan and valuation criteria resulting in a release (internal or external). 1 Each iteration should produce at least one tested software release. Iterations are typically measured in single digit weeks and not months.

KPA: Key Process Area a term used in the CMM. Each key process area identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for establishing process capability at that maturity level.


LOVEM: LOVEM® stands for "Line of Visibility Engineering Methodology" and is used by IBM in business process management projects worldwide. The business processes are described in "Bands". These represent the roles and organisational units but also the customers and the supporting IT systems. In this way, LOVEM® shows all elements of the business processes at a glance. Also, a detailed procedure model, which has been successfully applied and proven, is available in LOVEM® from which the strategic view of the business processes can be extended, and your interfaces and their relationships appropriately described.


MDA: Model Driven Architecture. Converting UML models into executable models / code. OMG effort.

mental model: are deeply ingrained assumptions, generalizations, or even pictures and images that influence how we understand the world and how we take action. Very often we are not consciously aware of our mental models or the effects they have on our behaviour. 3

modeling elements: An element that is an abstraction of the item being modelled. It is depicted in a standard diagram notation such as UML. An example of this could be an Actor. This represents a person or thing outside the system being modelled.
OO: Object Oriented.

OMG: Object Management Group.

Phase
: The time between two major project milestones, during which a well-defined set of objectives is met, artifacts are completed, and decisions are made to move or not move into the next phase.

PM: Project manager. Could also be Programme manager in some instances, depending upon the context.

Process: (1) A thread of control that can logically execute concurrently with other processes, specifically an operating system process. See also thread. (2) 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; in process engineering, the goal is to develop or enhance a process model; corresponds to a business use case in business engineering.
(1) A heavyweight unit of concurrency and execution in an operating system. Contrast: thread, which includes heavyweight and lightweight processes. If necessary, an implementation distinction can be made using stereotypes. (2) A software development process—the steps and guidelines by which to develop a system. (3) To execute an algorithm or otherwise handle something dynamically. 1

ProjectCentral: Web aspect of Microsoft Project.

QA: Quality Assurance.


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 supplementary specifications.1

RUP: Rational Unified Process.1

SCM: Software Configuration Management.

test: (1) A discipline in the software-engineering process whose purpose is to integrate and test the system. (2) n. an instance of a given test case (3). v. To execute a test. 1

Thread: An independent computation executing within an the execution environment and address space defined by an enclosing operating system process. Also sometimes called a "lightweight process".1

Tools specialist: The tool specialist is responsible for the supporting tools on the project. This includes selecting and acquiring tools. The tool specialist also configures and sets up the tools, and verifies that the tools work. 1

UCM: Unified Change Management.

UML: Unified Modeling Language.

UP: Unified Process.

use case (class): A description of system behaviour, in terms of sequences of actions. A use case should yield an observable result of value to an actor. A use case contains 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.
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.1

use-case model: A model that describes a system’s functional requirements in terms of use cases.1

VOB: Versioned Object Base.

Workflow: "The sequence of activities performed in a business that produces a result of observable value to an individual actor of the business."1

Home

Footnotes

1. Courtesy of RUP.

2. Zachman, John A.