-
A
-
-
activity
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 the selected process element. 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.
-
agile
- A set of values and principles for software development that use lean production techniques to deliver value to stakeholders quickly and frequently. See the agile manifesto at: http://agilemanifesto.org/
-
architectural mechanism
- 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 were made in forming the architecture as well as the global mapping between views.
-
artifact
- Artifacts are a specialized type of work product that represents tangible, non-trivial items that are consumed, produced, or modified by tasks. Artifacts may be composed of other artifacts and often serve as a basis for defining reusable assets.
-
assists
- Describes roles that may be consulted on task but are not actually assigned to perform the work.
-
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
-
C
-
-
capability pattern
A special type of process used to define a stereotypical way of performing work related to a particular subject. Capability Patterns are often used as course grained building blocks to assemble delivery processes.
-
checklist
- A specialized type of guidance that 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.
-
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
- A specialized type of guidance that outlines key ideas or basic principles that serve as foundation for additional information.
-
configuration
- The performance, functional, and physical attributes of an existing or planned product, or a combination of products.
-
Construction
- The third phase of the 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.
-
custom category
- Used to categorize content based on the user's criteria. One important use is for constructing views for publishing.
-
D
-
-
defect
- An anomaly, or flaw, in a delivered work product. Examples include such things as omissions and imperfections found during early lifecycle phases and symptoms of faults contained in software sufficiently mature for test or operation. A defect can be any kind of issue you want tracked and resolved.
-
deliverable
A specialized type of work prodcut used to define the primary outputs that represent value, material or otherwise, to the client, customer or other stakeholders. These are typically the result of packaging other work products for sign-off and delivery.
-
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 end-to-end lifecycle (for it's scope) and can be used as a reference for running projects with similar characteristics.
-
descriptor
- Defines how method content is represented in a process. Descriptors are the key concept for realizing the separation of proces from metho content. A descriptor has its own relationships and properties which can be modified independent of the default relationships defined in the method content.
-
discipline
Primary categorization mechanism for organizing tasks that define a major 'area of concern' and/or cooperation of work effort.
-
discipline grouping
- A collection of related disciplines defined for a specific usage or context.
-
domain
Primary catgorization mechanism for organizing work products that have an affinity to each other based on resources, timing, relationships or general subject area.
-
E
-
-
effort
The number of labor units required to complete an activity or other project element. Usually expressed as staff hours, staff days, or staff weeks. Should not be confused with duration.
-
Elaboration
- Second of four phases in the project lifecycle, when architecturally significant risks are addressed.
-
equivalence class
- A classification of equivalent values for which a object is expected to behave similarly. This technique can be applied to help analyze the most significant tests to conduct when there are too many potential tests to conduct in the available time.
-
estimation considerations
- A specialized type of guidance that describes the amount of effort to produce a work product or perform a task including any influencing factors.
-
example
A specialized type of guidance used to include typical samples of the items to be produced, may often only be a partial sample that is intended as further guidance rather than something to be reused.
-
exploratory testing
- A technique for testing computer software that requires minimal planning and tolerates limited documentation for the target-of-test in advance of test execution, relying on the skill and knowledge of the tester and feedback from test results to guide the ongoing test effort. Exploratory testing is often conducted in short sessions in which feedback gained from one session is used to dynamically plan subsequent sessions.
-
F
-
-
failure
- The inability of a system or component to perform its required functions within specified performance requirements [IE610.12]. A failure is characterized by the observable symptoms of one or more defects that have a root cause in one or more faults.
-
fault
- An accidental condition that causes the failure of a component in the implementation model to perform its required behavior. A fault is the root cause of one or more defects identified by observing one or more failures.
-
fault model
- A model for testing computer software which uses the notion of a plausible fault as it's basis and provides a test method to uncover the fault. The good fault model provides a definition of the fault or root cause, discussion of the observable failures the fault can produce, a test technique for uncovering the fault and a profile of appropriate test data.
-
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.
-
G
-
-
guidance
General term referring to all types of material that provide additional detail on other types of elements.
-
guideline
- A specialized type of guidance that provides additional detail on how to handle a particular method element. Guidelines most commonly describe how to perform some set of actions related to tasks or provide additional rules or recommendations related to the representation of work products.
-
I
-
-
Inception
- First of the four phases in the project lifecycle. It is about understanding the project scope and objectives and getting enough information to confirm whether the project should proceed or not.
-
Initial Operational Capability Milestone
Third major project milestone that occurs at the end of the Construction phase. At this point, the product is ready to be handed over to the Transition team. All functionality has been developed and all alpha testing (if any) has been completed. In addition to the software, a user manual has been developed, and there is a description of the current release. The product is ready for beta testing.
-
input
- In the UMA, input defines the work products needed to perform a task. These inputs are further categorized as being optional, mandatory or external. Optional inputs may be excluded from the task in some cases without consequences, while without mandatory inputs it is typically not possible to complete the task. External inputs are used to defined mandatory inputs that are the result of work outside the scope of the defined process.
-
iteration
A grouping of repeatable activities based on a set period of time that produces an expected set of results that has value. These results may be further refined in successive iterations.
-
Iteration
- Short and set duration division of a project. Iterations allow you 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 major project milestone that occurs at the end of Elaboration phase. At this point, a baseline of requirements is agreed to. Examine the detailed system objectives and scope, the choice of architecture, and the resolution of the major risks. The milestone is achieved when the architecture has been validated.
-
Lifecycle Objectives Milestone
First major project milestone, which occurs at the end of the Inception phase. At this point, compare the cost to the benefits of the project, and decide whether to proceed with the project or to cancel it.
-
M
-
-
method architecture
- A method architecture defines the concepts, their properties, and relationships for defining methods and processes. It is typically compromised of a meta-model, modeling language, or schema (synonyms) that is used for organizing large amounts of descriptions for management development methods and processes, such as software engineering, mechanical engineering, business transformation, sales cycles etc.
-
method configuration
- A method configuration specifies the selection of a logical subset of a method library, defined in terms of selected packages within plug-ins and any necessary views.
-
method content
Defines the primary reusable building blocks or reference materials of the method framework that exist outside of any predefined lifecycle. The basic content elements are: roles, tasks, work products and guidance.
-
method element
- There are two kinds of method element: method content and 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 elements.
-
milestone
A significant event in the project or sub-project, such as a major decision, completion of a deliverable, or meeting of a major dependency (like completion of a phase).
-
O
-
-
outcome
Specialized type of work products used to descibe intangible items such as the completion of some set of activities, a result or state. A key differentiator for outcomes against artifacts is that outcomes are not candidates for harvesting as reusable assets. Outcomes can not have associated templates or examples and are not possible to reuse as assets on other projects.
-
output
- Defines the results of performing some task in terms of the work products produced or modifed.
-
P
-
-
pattern
- Generalized solution that can be implemented and applied in a problem situation (a context)
-
performer
- Describes the roles that will be executing a task. There are two types of performs roles, a single primary performer responsible for the completion of the tasks and additional performers. There may be any number of additional performers and both are consided as allocated resources for the purposed of project scheduling.
-
phase
A specialized type of activity that represents a significant period in a project normally ending with a decision checkpoint, major milestones, or a set of deliverables. Phases typically have well defined objectives and provide the basis for how the project work will be structured.
-
Point
- A relative measure of size that is typically used for Agile estimation.
-
practice
- A specialized type of guidance that describes a proven way of doing something or common approaches and strategies that represent best practices. This is also used to represent standards and policies related to methods.
-
process
Describes the assembly of method content in a sequence or workflow that defines how the work will be executed. There are two types of processes: capability patterns and delivery processes.
-
Product Release Milestone
Fourth major project milestone that occurs at the end of the Transition phase. At this point, decide whether the objectives were met and whether you should start another development cycle. This milestone is the result of the customer reviewing and accepting the project deliverables.
-
project burndown
A primary report for understanding the status of a project. It typically consists of a chart showing the iterations in the horizontal axis and the remaining points from the work items list in the vertical axis.
-
R
-
-
report
- A specialized type of guidance used to provide guidance on representing the output of an automated tool that may be a combination of information from one or more other work products. .
-
Requirements
- A capability needed by the user to solve a problem [in order to] to achieve an objective
- 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 specialized type of guidance linking to intellectual capital that can be utilized to perform some task or leveraged as a starting point for the creation of a solution. This type of guidance is usually represented a link to some external source. This may include assets such as source code, templates, patterns, architectural frameworks, domain models, and so on - that can be reused in a different contexts.
-
risk
A potential event or future situation that can potentially affect, prevent, or limit a project's success. Project risks may be seen as threats or opportunities.
-
roadmap
- A specialized type of guidance that is specific to a process that represents a linear walkthrough of those items from a particular perspective.
-
role
Describes a standard set of responsibilities and corresponding skills necessary to perform a task or create a work product. A Role is not a job description the same person may execute several roles simultaneously or during the course of a project and a role may likewise be defined to represent a group such as a review board.
-
role set
- A specialized type of category used to organize roles by certain commonalities such as type of work, profession or area of knowledge.
-
role set grouping
- A specialized category used to organize role sets.
-
S
-
-
scope
The boundaries for inclusions and exclusions that define the depth and breadth of the project. Example of areas for consideration are included functionality, affected organizations, lifecycle phases performed, included and excluded deliverables, involved geographic areas, and so on.
-
smoke test
- A phrase used to describe a subset of tests-typically limited in number-that can be run against each software build to determine whether the software has regressed in form or function since a previous build. Synonyms: build validation test, build verification test, build acceptance test, build regression test and sanity check.
-
stakeholder need
- The business or operational problem (opportunity) that must be fulfilled to justify purchase or use of the system.
-
step
- Sub-section of a task used to organize the work to be performed to achieve the overall goal of the task. Not all Steps are necessarily performed each time a task is executed in a process.
-
stub
- A component containing functionality for testing purposes. A stub is either a pure "dummy", just returning some predefined values, or it is "simulating" a more complex behavior.
-
supporting material
- A guidance that is a catch-all for other types of guidance not specifically defined elsewhere.
-
system-wide requirements
- System-wide requirements are 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
-
-
target test item
- An aspect of the developed product-typically software or hardware-which has been identified as a target of the testing effort. A target test item might be scoped at the level of an operation, interface, feature, component, subsystem, or system; or it may be an external aspect of the system, such as an operating system or peripheral device (eg printer).
-
task
Defines a unit of work that needs to be done in order to transfrom inputs into outputs through a series of steps performed by one or more roles independent of a particular work breakdown structure (WBS).
-
team profile
- A breakdown element that groups role descriptors or composite roles, thus defining a nested hierarchy of teams and team members.
-
template
- A specialized type of 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. Often provided as a form or empty instanced of a work product that can be used as starting point for the creation of a new one.
-
term definition
- A specialized form of guidance that provides definitions that are used to build up the glossary
-
test case
- The specification (usually formal) of a set of test inputs, execution conditions, and expected results, identified for the purpose of making an evaluation of some particular aspect of a target test item. A test case differs from a test idea, in that the test case is a more fully-formed specification of the test, describing what the test(s) that result form the test case will be required to do.
-
test environment
- A specific instance of a configuration of hardware and software established for the purpose of conducting tests under known and controlled conditions.
-
test idea
- A brief statement identifying a test that is potentially useful to conduct. The test idea typically represents an aspect of a given test: an input, an execution condition or an expected result, but often only addresses a single aspect of a test. A test idea differs from a test case, in that the test idea is an incomplete definition containing no specification of the test workings, only the essence of the idea behind the test. Synonym: test requirement. See also: test case.
-
test oracle
- A strategy for knowing whether a test passes or fails. The test oracle includes both the medium through which the output from the test can be observed, and the technique for interpreting what that medium exposes. It provides a means by which observed results can be evaluated against expected results.
-
test requirement
- A requirement placed on the test effort that must be fulfilled the implementation and execution of one or more tests. This term has been superseded by the term test idea.
-
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 appy a specific tool to accomplish a task, perform a set of steps or instantiate a particular work product.
-
Transition
- The fourth and last phase of the 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 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
- Structured content collections designed to drive publication and facilitate browsing. They are specified using custom categories.
-
W
-
-
white paper
A specialized type of guidance for externally published papers that can be read and understood in isolation of other content elements.
-
work breakdown structure (WBS)
A significant event in the project or sub-project, such as a major decision, completion of a deliverable, or meeting of a major dependency (like completion of a project phase). Note: milestone is commonly used to refer to both the event itself and the point in time at which the event is scheduled to happen.
-
Work Item
- Scheduled work to be done within the project.
-
work product
Used to define and describe the items needed as input or created as output of one or more tasks that are the responsibility of a single role. See: artifact, deliverable, outcome.
-
work product kind
- A specialized type of category used to organized work products based on their intended usage or type.