Glossary

Denotes the root of the Polarion installation in documentation. For Windows systems, the default value is C:\Polarion. For Linux systems it is the location of the binaries, usually /opt/polarion/.

The area of Polarion used by administrators for managing the system configuration, customization, user accounts, and so forth. Access requires administrator permissions on the user's account. Permission may be granted globally for the repository, or for one or more specific projects. When a user account has the required permission for the scope, the Administration link appears in the Polarion header enabling the user to access administration topics and features.

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 piece of information that is used or produced by a software (or application) development process.

In Polarion documentation, the term can apply to Work Items. It is generally applied to units of blocks of information in an external office document which become Work Items when the document is imported into Polarion.

A work product (such as software or documentation) that has been formally reviewed, approved, and delivered and can only be changed through formal change control procedures.

In Polarion, a Baseline record for a project or repository created in the Baselines topic.

Achieved when the traceability chains can be demonstrated in both directions, ensuring that the end product meets all of the requirements, and only the requirements specified.

In Polarion, the possibility to trace from an artifact/Work Item up to a linking parent item or down to a linked item.

The smallest buildable entity. Comprised of resources - usually source code and support files.

Builds of projects are configured in Administration in the Builds topic.

A standard data field of Work Items for the purpose of categorizing them. When Work Items are assigned one or more Category values, they can be queried by Category. For example, if category User Interface is defined, Work Items relating to user interface development can be assigned that category. It is then simple to query for Work Items having a Category value matching that "User Interface".

Categories can be defined for each project in Administration Work Items Categories.

See: Wiki Page.

Content Pane is a part of user interface, where you can read project information (wiki pages or Work Items, for example) and edit content.

A special wiki-based page that rolls up and displays key status information based on actual progress data automatically maintained by Polarion. Information can be viewed for an entire repository, a group of projects, or a single project.

(Not all Polarion products have this feature.)

Document (capitalized) in documentation refers to a Live Document.

A list of values that users can select from and apply to some Work Item field. For example, Work Item types are defined in an enumeration (Administration Work Items Enumerations).

A standard data field of Work Items, it represents the amount of time initially estimated for completing a Work Item. Values in this field are used by the Live Plan planning engine when generating a project plan.

See also Remaining Estimate.

A type of Page that does not contain user-configurable report Widgets which retrieve display project and Work Item data. The term is simply to distinguish such Pages from LiveReport Pages that do contain Widgets. Technologically, there is no difference. A Page created as an Info Page can contain Widgets.

Polarion enables viewing and management of information for an entire repository, for a group of projects, or a single project. The information scope refers to the breadth of information you are currently working with. The Repository scope means just that: you are working with or looking at information from all projects in a repository. For example, the Dashboard topic in this scope (in products which have the feature) rolls up status information from all projects to provide a view on the overall status of development across all projects managed with Polarion.

A named version of the Polarion user interface that displays some subset of all available information to facilitate some role or work context, for example, "Manager" or "Developer". An Interface can show or hide Navigation topics, invoke some particular view on Work Items, show or hide Work Item fields, and control the layout of Work Item fields.

Interfaces are configured in the Interfaces topic of Administration.

A predefined system process that may be initiated either by system or by user. Examples of jobs include backups and builds. Administrators can define jobs and job scheduling.

A descriptive word or words applied to a link between two Work Items that describes the relationship between those items. For example, a link role "depends on" may be defined and applied to a link between two Work Items when one of the linked items has some dependency upon the other one.

A control that limits the application of link roles between Work Items of one or more specified types. For example, if a link role should be applicable to links between Work Items of type A and B, but not to links between Work Items of type A and C, a link role rule can be defined that enforces this. When this link role rule exists, users are prevented from specifying such a link.

An artifact-aware online document that can contain Work Items of one or more types. LiveDocs, (referred to in documentation as "Documents") are ideal for creating specifications for such things as requirements or test cases. Work Items defined in a LiveDoc can be managed in the same way as those defined directly in the integrated tracker (that is the Work Items topic in Navigation).

Prior to version 2011, the term referred to Microsoft Office Word and Excel documents, based on special document templates, which could define and store Polarion Work Items. While useful for some, this approach had drawbacks, especially in terms of scalability. Beginning with version 2011, Polarion refactored the technology completely. Users having projects containing pre-2011 Microsoft Word and Microsoft Excel documents (created with Polarion version 2010 or earlier) are recommended to migrate to the current LiveDocs implementation. Legacy documents are no longer indexed and consequently do not appear in query results. If you have legacy documents and need to have them included in the index, please contact Polarion ALM technical support.

"LiveDoc" may also refer to Polarion's artifact-aware online document technology.

See LiveDoc above.

The feature of some Polarion products which automatically calculates a project plan based on a number of input parameters including project start and end dates, Time Points and Work Items assigned to them, estimated time and time worked on Work Items, human capacity based on working calendars, and many other factors.

The term can refer not only to the Live Plan engine, but also the GANTT-style chart of the project plan rendered by the engine in the Live Plan view of the Work Items topic, and in the Live Plan section of the Dashboard topic (in products that provide these features).

A type of Page that contain user-configurable report Widgets which retrieve display project and Work Item data. The term is simply to distinguish such Pages from others that do not contain Widgets. Technologically, there is no difference.

A Module was a special container for Work Items in Polarion versions prior to version 2011. It is now deprecated in favor of Polarion LiveDoc Documents.

Navigation pane is the part of user interface where a user is able to select available topics the present features, functionality, and information.

An orphaned Work Item is a Work Item which was originally defined in a LiveDoc and later unmarked or merged with another Work Item in the Document. The orphaned Work Item no longer appears as such in the document, but the artifact still exists in the underlying repository. It is therefore subject to workflow control and all other management features. The Recycle Bin pane of the Document Sidebar provides tools for managing orphaned Work Items.

When capitalized, refers to a portal web page that contains information that is not tracked and workflow-managed through a process.

Content of Pages cannot be marked and managed as Work Items. However, Pages may display Work Item data via special report Widgets. Pages can have hyperlinks to other internal and external URLs. Pages have a palette of rich formatting tools, and can display images and contain file attachments.

A set of repeatable steps with a clearly defined beginning and end.

In Polarion, a process is encapsulated in a project's workflow configuration and managed by setting different values in the Status field of Work Items as the item tracks through the process steps.

An undertaking requiring effort that is constrained by limited resources, and is planned, executed, and controlled.

In Polarion, the term can also refer to a folder in a Polarion repository that stores and manages all artifacts relating to some specific development activity or goal. A project's folder is marked as a project by Polarion when an administrator creates a new project.

A standard data field of Work Items, it represents the difference between the amount of time initially estimated for completing a Work Item, and the amount of time already reported spent working on it. Values in this field are used by the Live Plan planning engine when generating a project plan.

See also: Initial Estimate.

Polarion's underlying data storage and history mechanism. Currently, the open source version control system Subversion is used for this purpose. All development artifacts including Work Items, wiki pages and documents are stored and versioned in the repository.

By default, a single Subversion repository is created when Polarion is installed. With appropriate licensing and IT infrastructure, Polarion can support multiple repositories

A specific business result that is needed to solve a problem or achieve an objective.

In Polarion, the term often refers to an artifact or Work Item type which defines a requirement as per the definition above.

A query string either manually entered or built by the Query Builder which is saved for later reuse. Saved queries appear in the drop-down panel of the Query Builder in Work Item views in the Work Items topic. Saved queries can be shared globally for all platform users, or for all users of a specific project. Individual users can also create "private" saved queries which are available only to them.

Saved Queries differ from Shortcuts in that they only retrieve Work Items and are available only in the Work Items page.

See Information Scope.

A special link in Navigation that takes the user to specified saved subset and presentation of information. Shortcuts can be shared globally for all platform users, or for all users of a specific project. Individual users can also create "private" shortcuts which are only available to them.

Shortcuts differ from Saved Queries in that they are not limited to retrieving Work Items, and they can retrieve presentation as well as data.

An abbreviation for Subversion, a leading open source version control system used by Polarion to store all artifacts of the application development process.

A type of Work Item which defines a set of steps for testing some defined functionality or feature of an application. Polarion project templates which provide QA/testing support pre-define a Work Item type named "Test Case". (Project administrators may change the actual name of this type, or create some other type which is analogous to it.)

Test Case items may created and defined either in a Document or directly in the integrated tracker (NavigationWork Items).

A business object which encompasses a set of Test Cases (which usually define manual tests) or unit tests (normally automated tests) to be executed, together with information about the status of the Test Run, results of execution of the Test Run and the Test Cases or unit tests which it encompasses, the test environment, and the build tested.

A named milestone or development deadline associated with a date. Time Points are most commonly created for projects by a project manager/administrator. Work Items can be assigned to a Time Point by project managers or other users with the necessary permissions. When assigned to a Time Point, Work Items are processed by the Live Plan engine and shown in the project plan (Live Plan view of the Work Items topic and the Live Plan section of the Dashboard topic).

A person or computer-based process that interacts with Polarion. An "end user" is a Polarion user who does not have administrator permissions.

For a glossary of terms related to variants and variant management, see Terminology.

A named representation of a set of Work Items in which the retrieved items are presented in some specific format or context. For example, the Table view renders Work Items as table, the Tree view renders Work Items as a hierarchical tree of linked items, the Matrix view renders two sets of Work Items in a matrix format. The Road Map view renders Work Items associated with a defined point in time.

A user-configurable visual report component that can be inserted into LiveReport Pages and which retrieve and visually format project and Work Item data in useful ways in real time.

DEPRECATED. A unitary online document that uses Polarion's initial wiki technology from prior to version 2015. Now referred to in documentation as "Classic Wiki page".

Content of Wiki Pages cannot be marked and managed as Work Items. However, Wiki Pages may display Work Item data from the integrated tracker by means of macros which contains query language that retrieves some set of Work Items and dynamically displays it in a Wiki Page. Pages can have hyperlinks to other Pages and/or external URLs, and/or to tracker pages. Pages can display images and contain file attachments.

Polarion's term for a tracked and managed system artifact that represents some issue to be processed, or element of work to be done. Work Items are a key element in the workflow of a project.

A rule, defined (and optionally saved for reuse) when importing a Microsoft Office Word document into Polarion as a LiveDoc, which causes Polarion to recognize content in the source document as a Work Item.

Work Items have a property type which describes the basic nature of the issue or work. Examples of common Work Item types include:

• Defect

• Change Request

• Requirement

• Task

Administrators can create custom Work Item types to support any process, semantics, and workflow.

The feature of Polarion that encapsulates a process and subsequently controls and automates the progress, and reflects the status of Work Items from their inception until they are resolved/closed.

Polarion products come with predefined workflows suitable for many types projects. Administrators can customize workflow to support any process or methodology used by an organization to develop applications.

An action invoked by a user or a job that changes the status of a Work Item. For example, suppose a project has statuses Open and Accepted defined for Work Items. Suppose also that it has a workflow action Accept defined. When set by a user, the Accept action triggers transition of the Work Item status from Open to Accepted.

An artifact defined for Work Item workflows which transitions them from one defined status to another (from Open to Accepted, for example), resulting in notifications, history entry, etc.

A multivalued data field for Work Items. It enables the assignee(s) of a Work Item to record multiple blocks of time spent working on the item. The aggregated time from all work records is added to any value in the Time Spent field, and that value is used to update the Remaining Estimate field. Using Work Records is optional.