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.

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 capability pattern is 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 a practitioner to guide their work.

component
  A nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the realization of a set of interfaces
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/ Basic 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 providestep-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.
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, Analysis & Design, Implementation,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
  A specific problem category that is characterized by a body of knowledge, activities, and behaviors.
domain

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

  (2)Refineable hierarchy grouping 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 in the OpenUP/ Basic project lifecycle, when architecturally-significant risks are addressed
F
Feature
  An externally observable service provided by the system that directly fulfills a Stakeholder Need .
FURPS+
  Functionality, usability, reliability, performance, supportability + others. This acronym represents categories that can be used in the definition of product requirements. For more information see Supporting Requirements
G
glossary
  An artifact in OpenUP that defines 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.

I
Inception
  First of the four phases in the OpenUP/ Basic 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.
  At the end of Construction phase is the third important project milestone.
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 tool 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
  At the end of the Elaboration phase is the second important project milestone
Lifecycle Objectives Milestone
  At the end of the Inception phase is the first major project milestone
M
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.

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 solutions 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 is typically used for Agile estimation
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.

Product Release Milestone
  At the end of the Transition phase is the last major project milestone
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
Requirement

  A formal statement of: (1) An attribute to be possessed by the product or a function to be performed by the product. (2) the performance standard for the attribute or function. (3) the measuring process to be used in verifying that the standard has been met. [ICS03]

risk
  A condition that can potentially affect, prevent, or limit a project's success. Project risks may be seen as threats or opportunities
role
  A definition of the behavior and responsibilities of an individual, or a set of individuals, working together as a team.
role
  A definition of the behavior and responsibilities of an individual, or a set of individuals working together as a team, within the context of a business organization. Examples of roles include Analyst, Developer, and Tester.
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 requirements
  System-wide requirement not captured in scenarios or use cases. Supporting Requirements may be categorized according to the FURPS+ model (Functionality, Usability, Reliability, Performance, Supportability + Constraints).
T
task
  A unit of work a role may be asked to perform.
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 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/ Basic 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 alternate ways that the system provides a behavior, or it may describe failure or 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 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
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.