A
activity

An activity is something that one or more roles do.

In the UMA , an activity is a breakdown element which supports the nesting and logical grouping of related process elements such as descriptor and sub-activities, thus forming breakdown structures.

activity detail diagram
Diagram depicting all the breakdown elements within the scope of an activity. This diagram also depicts input/output relationships between tasks, activities, and work products; as well as responsibility relationships between roles and tasks. Activity detail diagrams are used to provide a complete summary of an activity and thus improve their comprehensibility.
actor
Someone or something outside the system that interacts with the system.
agile
A set of values and principles for software development that use lean production techniques to deliver value to stakeholders quickly and frequently.
analyst
Role representing customer and end-user concerns.
architect
Role representing someone responsible for designing the software architecture, which includes making the key technical decisions that constrain the overall design and implementation of the project
architectural mechanisms
Architectural mechanisms represent common concrete solutions to frequently encountered problems. They may be patterns of structure, patterns of behavior, or both.
architectural view
A view of the  architecture from a given perspective.
architecture
Describes the blueprint for software development, frequently represented using a number of architectural views. It also contains the rationale, assumptions, explanations and implications of the decisions that where made in forming the architecture as well as the global mapping between views.
artifact
A formal work product that:
1) is produced, modified, or used by a task,
2) defines an area of responsibility
3) is subject to version control.

An artifact can have multiple forms including a model, a model element, or a document.

attribute
Attributes are properties of entities such as (but not limited to) Work Items, Use Cases and Tests. Attributes capture important additional information about the entity that can subsequently be used to answer queries about the status of the development project.
B
breakdown element
Any element modeled in UMA that is part of process structure.
breakdown structure

A UMA construct that specifies a process as the hierarchical composition of breakdown elements.

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.
business rule
A declaration of policy or condition that must be satisfied by the system under consideration. For more information see supporting requirements.
C
capability pattern

A special process that describes a reusable cluster of activity. Capability patterns express and communicate process knowledge for a key area of interest such as a discipline and can be directly used by practitioners to guide their work.

checklist
Identifies a series of items that need to be completed or verified. Checklists are often used in reviews such as walkthroughs or inspections.
code instrumentation

"Extra" statements added to source code for the purposes of testing, debugging, tuning, or tracing.

collaboration
A group of people cooperating together to solve a clearly defined and meaningful business problem. High collaboration requires an environment of trust where dialog is disciplined and focused on resolving the business problem.
component

An encapsulated part of the system that is nontrivial, nearly independent, and replaceable and that fulfils a clear function in the context of well-defined architecture. A component conforms to and provides the realization of a set of interfaces.

composite role
A special role descriptor that relates to more than one role. It represents a grouping of roles with the main purpose of reducing the number of roles defined in method content for a process.
concept
Outlines key ideas or basic principles underlying a topic central to the method. Concepts normally address more general topics than guidelines and span across several work products, tasks, or activities.
configuration
The performance, functional, and physical attributes of an existing or planned product, or a combination of products.
Construction
The third phase of the OpenUP project lifecycle, 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.
content element
Any element modeled in UMA that is part of method content. Content elements provide step-by-step explanations, describing how very specific development goals are achieved independent of the placement of these steps within a development lifecycle. They are instantiated and adapted to the specific situation within process structures.
content package
A special method package that contains content elements exclusively. Examples for content element are artifacts, tasks, roles, and guidance.
custom category
Used to categorize content based on the user's criteria. One important use is for constructing views.
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 or may not be the user. The customer is the ultimate recipient of the developed product. See also: stakeholder.
D
deliverable
An output from a process that has a value, material or otherwise, to a customer or other stakeholder .
delivery process
A delivery process is a special process describing a complete and integrated approach for performing a specific project type. It provides a complete lifecycle model that has been detailed by sequencing method content in breakdown structures.
descriptor
In the UMA, a description is an abstract generalization for special breakdown elements that reference one concrete content element. Descriptors are the key concept for realizing the separation of process from Method Content. A descriptor can be characterized as a reference object for one particular content element. In addition, a descriptor has its own relationships and properties whose purpose is to modify the semantics of the content element it refers to.
developer
Role representing someone responsible for developing a part of the system, including designing it to fit into the architecture, and then implementing, unit-testing, and integrating the components that are part of the solution.
discipline
A collection of related tasks that define a major 'area of concern'. In software engineering, Disciplines include: Requirements, Architecture, Development,Test, and Project Management.
document
A document is a collection of information intended to be represented on paper, or in a medium using a paper metaphor. The paper metaphor includes the concept of pages, and it has either an implicit or explicit sequence of contents. The information is in text or two-dimensional pictures. Examples of paper metaphors are word processor documents, spreadsheets, schedules, Gantt charts, web-pages, and overhead slide presentations.
domain

(1)An area of knowledge or activity characterized by a family of related values.

(2) A specific problem category that is characterized by a body of knowledge, activities, and behaviors.

(3)A refineable hierarchy that groups related work products. 

E
effort

Indicates how long it will take the team member(s) assigned to the work item to do the work. Typically uses the units of actual days or actual hours.

Elaboration
Second of four phases in the OpenUP project lifecycle, when architecturally-significant risks are addressed
example
A guidance that represents a typical, partially completed, sample instance of one or more content elements. Examples are most commonly provided for work products.
F
feature
An externally observable service provided by the system that directly fulfills a stakeholder need.
FURPS+
Functional, usability, reliability, performance, supportability and others. This acronym represents categories that can be used in the definition of product requirements. For more information see supporting requirements.
G
glossary
Captures the vocabulary and other important terms that are part of a project and the problem domain.
guidance

Guidance describes proven advice for accomplishing a goal. 

In the UMA, guidance generalizes all forms of content whose primary purpose is to provide explanations about other UMA elements. Guidance being itself a content element, it is possible to associate guidance to other guidance.

guideline
A guidance that provides additional detail on how to handle a particular content element. Guidelines most commonly apply to tasks and work products.
I
Inception
First of the four phases in the OpenUP project lifecycle, it is about understanding the project scope and objectives and getting enough information to confirm that the project should proceed or not.
Initial Operational Capability Milestone

Third important project milestone that happens at the end of Construction phase. At this point, the product should be ready to be handed over to the transition team.

input
In the UMA, input is a type of work product used by a task See: static work product.
iteration
Short and time-boxed division of a project. Iterations allow to demonstrate incremental value and obtain early and continuous feedback.
iteration burndown
A primary report for understanding the status of an iteration. It shows the trend for how much work is left to do within that iteration.
L
Lifecycle Architecture Milestone

Second important project milestone that happens at the end of Construction phase. At this point, a baseline of requirements has been agreed to, detailed system objectives and scope have been defined, architecture should be baselined, and major risks resolved.

Lifecycle Objectives Milestone
First major project milestone that happens at the end of Inception phase. At this point, there has been consensus about the cost versus benefits of the project, and decision on either to proceed with the project or to cancel it can be made.
M
method configuration
A method configuration specifies the selection of a logical subset of a method library, in terms of method plug-ins, content packages and process packages.
method content

Describes generic UMA methodological concepts and guidance which provide step-by-step explanations, describing how specific goals are achieved independently of the placement of these steps within a process lifecycle. UMA separates method content from its application in process.

method library
A physical container for method plug-ins and method configuration definitions. All method elements are stored in a method library.
method plug-in
Represents a physical container for method packages. It defines a largest granularity level for the modularization and organization of method content and processes.
milestone

The point at which an iteration or phase formally ends, thus providing a check-point for whether the project is ready to move to the next iteration or phase.

model

A model is an abstraction of a more complicated thing.




model element
An element that is an abstraction drawn from the system being modeled. Contrast: view element.
O
outcome

Primarily describes intangible work products that are a result or state. An outcome can also be used to represent an informal work product.

output
(1) Any work product that is the result of a task. See: deliverable.
P
pattern
Generalized solution that can be implemented and applied in a problem situation (a context).
phase
The time between two major project milestones, during which a well-defined set of objectives is met, and decisions are made to move or not to move into the next phase.
point
A relative measure of size that is typically used for Agile estimation.
practice
A guidance that presents a proven way or strategy of doing work to achieve a goal that has a positive impact on work product or process quality.
process

(1) A general structure for particular types of development projects. Processes take content elements and relate them into semi-ordered sequences that are customized to specific types of projects. Thus, a process is a set of partially ordered work descriptions intended to reach a higher development goal, such as the release of a specific software  These work descriptions are organized into a hierarchical breakdown-structure A process focuses on the lifecycle and the sequencing of work in breakdown structures.

(2) The part of  UMA that models processes.

process contribution
A special process that externally defines additions and changes to an existing process without directly modifying it.
process package
A method package that contains processes such as capability patterns or delivery processes only.
Product Release Milestone
Fourth important project milestone that happens at the end of Transition phase. At this point, objectives should have been met, and another development cycle could start. This milestone is the result of the customer reviewing and accepting the project deliverables.
project burndown
A chart consisting of two perspectives, the horizontal axis showing the iterations and the vertical axis indicating the remaining points from the work items list.
R
release
The delivery of a functional system meeting predefined objectives.
report
A guidance that is a predefined template of a result generated on the basis of other work products. An output from some form of tool automation.
requirement
  1. A capability needed by the user to solve a problem [in order to] to achieve an objective.
  2. A capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documentation [THA00].
reusable asset
A guidance that describes an asset - such as source code, templates, patterns, architectural frameworks, domain models, and so on - that can be reused in a different context.
risk
A condition that can potentially affect, prevent, or limit a project's success. Project risks may be seen as threats or opportunities.
roadmap
A guidance that summarizes a process, often from a particular perspective, such as by providing a walkthrough with a linear thread of a typical instantiation of activities.
role
A definition of the behavior and responsibilities of an individual, or a set of individuals working together as a team.
role set
Used to group roles with certain commonalities together.
S
scope
A description of the breadth of a system's behavior, specifying the boundaries of the problem domain or system.
stakeholder
An individual who is who is materially affected by the outcome of the process (i.e. the deliverables the process produces).
stakeholder need
The business or operational problem (opportunity) that must be fulfilled to justify purchase or use of the system.
static work product
A work product that is used, but not changed, by a process.
step
In the UMA, a step is content element used to organize tasks into parts or subunits of work.
supporting material
A guidance that is a catch-all for other types of guidance not specifically defined elsewhere.
supporting requirements
Requirements that define necessary system quality attributes such as performance, usability and reliability, as well as global functional requirements that are not captured in behavioral requirements artifacts such as use cases.
T
task
A unit of work a role may be asked to perform.
team profile
A breakdown element that groups role descriptors or composite roles, thus defining a nested hierarchy of teams and team members.
template
A guidance that specifies the structure of a work product by providing a pre-defined table of contents, sections, packages, and/or headings, a standardized format, as well as descriptions on how the sections and packages are supposed to be used and completed.
term definition
A guidance that defines concepts that are used to build up the glossary.
test case

The specification of a set of test inputs, execution conditions, and expected results, which need to be validated to enable an assessment of some particular aspects of the system under test.

tester
Role representing someone  responsible for the core activities of the test effort.
tool
A standard category used as a container for tool mentors. It can also provide general descriptions of the tool and its general capabilities.
tool mentor
A tool mentor is a type of guidance that explains how to perform specific task or steps using a specific software tool.
Transition
The fourth and last phase of the OpenUP project lifecycle, which results in a final product release.
U
UMA
Stands for Unified Method Architecture. UMA is a state-of-the-art architecture for the conceiving, specifying, and storing of method and process metadata.
use case
Captures requirements as a sequence of actions a system performs that yields an observable result of value to those interacting with the system.
use-case model
A model of the system use cases and actors and the relationships between them.
use-case scenario
Represents specific instances of the use case that correspond to specific inputs from the actor or to specific conditions in the environment. Each scenario describes alternative ways that the system provides a behavior, or it may describe failure and exception cases.
V
velocity
A key metric used for iteration planning. It indicates how many points are delivered upon within an iteration for a certain team and project.
version
A variant of some artifact; later versions of an artifact typically expand upon earlier versions.
view
Structured content collections designed to drive publication and facilitate browsing. They are specified using custom categories.
view element
A view element is a textual and/or graphical projection of a collection of model elements.
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.
W
white paper

A guidance type for externally published papers that can be read and understood in isolation of other content elements and guidance.

work breakdown structure
Breaks the project into individual units of work, or tasks, for which cost, milestones, and activities can be allocated and tracked.
work item
Scheduled work to be done within the project.
work product
In the UMA, a work product is a content element that represents anything used, produced, or modified by a task.
work product kind
Standard category that represents a grouping of related work products which, in contrast to domain, is more presentation oriented (like models, specifications, plans, and so on).