This chapter of the Polarion User Guide provides information about Polarion features and common tasks that are of interest mostly for project managers. Of course some features and topics may overlap with information for software developers or system administrators. In such cases, this chapter may contain only a cross reference to information elsewhere in the documentation.
When you are planning to manage a project with Polarion, there are quite a number of issues to think about. The prefabricated project templates that come with the different products are a good way to get many projects up and running quickly. But other projects may require more thought, planning, and customization. Where do you begin, and what issues should you think about and explore? This section deals with exactly that. Not every issue or every customization mentioned may apply to your situation, but you can only decide that if you are aware of the possibilities. So let's begin with an overview of the Polarion features and configurations to consider when gearing up for a new Polarion project.
As mentioned above, Polarion products come with one or more project templates. These have been carefully designed to provide artifact types, workflows, system configurations, and content that support different types of projects. For a list of the default project templates distributed with different Polarion products, see User Reference: Default Project Templates.
In addition to the default project templates included product distributions, the Polarion Extensions portal has more project templates, which you can download and add to your Polarion installation. You can find these at http://extensions.polarion.com.
Looking into project templates should be a project manager's first step in planning for a new project. There is a good chance the one of the available templates will provide everything needed for your project. A good way to do this is to create sandbox projects on your own Polarion server. Create test projects using the templates that seem closest to what you need, then look at them in terms of the issues discussed in the following sections to see if the template provides what you need, and if not, what you might need to customize to get you there.
To learn how to create a project using a project template, see Administrator's Guide: Creating a New Project From a Template. To learn about customizing project templates, see Administrator's Guide: Customizing Project Templates.
The default project templates provide predefined Work Item types that work well for many software development projects. Therefore, you will see such types as "Requirement", "Defect", "Change Request" and "Test Case". But keep in mind is that Work Item types can represent literally anything you need them to represent.
In your planning, think about what kinds of artifacts you would need to have represented and processed, and consider creating custom Work Item types for them.
Work Item types are defined in the enumeration configuration file
workitem-type-enum.xml (Administration >
Work Items > Enumerations). For more information see Administrator's Guide: Configuring Enumerations.
Hand in hand with thinking about custom Work Item types goes thinking about what relationships can exist between items of your custom types. The "standard"
types provided for software development typically have relationships like "depends on", "relates to", "implements", "verifies", etc. These relationships
are defined in link roles, and these can be customized to define whatever relationships you need between your types of Work Items.
Then in production, links with one or more link roles can be created between Work Items of your types, thereby creating exactly the kind of traceability you need.
Link roles are defined in another enumeration configuration file:
workitem-link-role-enum.xml (Administration >
Work Items > Enumerations). For more information see Administrator's Guide:
Let's assume you have defined several custom Work Item types, and the link roles that cover all the relationships that can exist between these types. But suppose some of those relationships should actually exist only between certain types, and never between other types? For example, suppose you have a link role "fixes" for a relationship that can exist between Work Item types "Repair" and "Breakdown", but should never exist between Work Item types "Breakdown" and "Sales Call". That's where Link Role Rules come into play. For each link role you define, you can also define one or more rules that control between which Work Item types users can create links with that link role. You can configure the rules on the same page where you define the link roles.
For more information, see Administrator's Guide: Link Roles and Rules.
Regardless of whether or not you need custom Work Item types and link roles (but especially if you do), you will want to take a close look at the workflow customization capabilities for Work Items, Documents and Test Runs. Again, the Project Templates provided with the different products provide workflow configurations that are suitable for many projects and processes. If the predefined workflows in the project templates do not meet your needs, your administrator can configure the workflows for your project to support your process.
Workflow enables you to embed process knowledge right in the project to ensure that everyone on the team complies with the process, even though they may not know all its details. Workflow makes process compliance seamless and painless. You can set up workflows to ensure that no steps are missed, that the steps progress in the correct order, and that the right things happen after steps in the process are completed. A good example is the workflow configured for the standard Requirements Project template provided with some products. Requirement type Work Items go through a process or review and approval before they go into the implementation phases, and after that phase, they automatically enter the testing phase. Workflow can be circular. For example, if a Requirement is not approved, it reverts back to an in progress state, or if a test discovers a defect, it reverts back to an unresolved state.
Polarion supports U.S. 21 CFR Part 11 compliant electronic signatures. Requiring signatures for specific actions or process steps can be configured in the global workflow configurations for Work Items, Documents and Test Runs (as default for all new projects) and individually in these workflows in individual projects, overriding the global configurations with project-specific statuses and transitions.
Polarion provides a default set of data fields for Work Items which are adequate for many teams and projects. But if you need to track additional data with Work Items, you are not limited to the default fields. You can define custom fields of various data types. You can make them applicable to all Work Item types, or limit them to one or more specific types, and you can optionally define them as required fields. For example, if you have several products and Work Items are somehow applicable to a specific product, you might create a custom field "Product" (and possibly an enumeration to store a list of products from which users can pick a value when filling in the custom field). Custom fields can also be used as search parameters in queries. For example, if you have a custom "Product" field, users can query for Work Items having some value in that field.
So in planning for a new project, give some though to what additional data you need to track for each Work Item type and plan to create custom fields to track it. You define custom fields in Administration > Work Items > Custom Fields. For more information, see Administrator's Guide: Configuring Custom Fields.
You can configure your project to automatically assign newly created Work Items to team members based conditions which you specify. This can save a great deal of time over the life of a project and more than pay back the time spent to set up the auto-assignment rules. Conditions can range from simple (assign all new items to the project leader, for example), to highly complex where assignment depends on multiple conditions and values set in several Work Item fields. For example, a complex condition might be that the item is assigned to some Category, and it has a certain severity level, and it is assigned a specific Time Point. When the condition is satisfied, then the new Work Item is automatically assigned to one or more assignees specified in the auto-assignment rule. For example, auto-assignment rules might be created so that a new Work Item with Category value "User Interface" with a severity level "Major" or "Critical" is automatically assigned to user A, while an item with the same Category value but with severity level "Normal" or "Trivial" is automatically assigned to user B.
Automatic Work Item assignment is configured in Administration > Work Items >Auto-assignment. For more information see Administrator's Guide: Configuring Auto-assignment.
The standard Work Item field "Category" enables you to classify Work Items in one or more ways. Categorizing your project's Work Items provides an additional way to query them. This in turn can be useful for reporting certain subsets of a project's Work Items on wiki pages for stakeholders who do not use the tracker. For example, you might have a category "Usability" for Work Items that somehow relate to that issue. You can then easily construct a query to retrieve, for example, all items in having the Usability category set for them, and that were resolved for some time point. You can easily embed that query in a wiki macro that will display the query results on a wiki page. Categories can also be useful in automatically assigning newly created Work Items.
You can define Categories for your project in Administration > Work Items > Categories. For more information, see Administrator's Guide: Configuring Categories.
This issue is comparatively simple, but it's one you should think about to make sure your project launches without hitches. You should make sure that everyone on your project team has a user account, and that they have to permissions they need to work on the project. The same goes for any other stakeholders. You may want to look at the global user roles on your Polarion system, and decide if these are right for your project, or whether you will need to define project-local roles. For any such roles, you'll need to consider what permissions are needed for users having each role. For example, suppose you have a project-local role "project_customer" for some external user(s) at your customer's company. You may want that role restricted from accessing some kinds of data... Work Item comments or time estimates, for example... and maybe also restricted from changing data.
To learn more about these issues, see Administrator's Guide: User Management in Polarion.
Polarion's approach to creating a project plan is probably different from that of other project planning tools you may have used. With Polarion, you create Work Items for everything that must be done to complete the project. These are assigned to team members to process. You create Time Points corresponding to milestones like iterations and releases and as part of your planning, assign Work Items to these. On each Work Item, you and/or team members estimate the amount of time needed to resolve it. You also need to check your available working time as configured in the global Working Calendar (open Repository, then Administration > Work Items > Working Calendar) and have your team members configure their personal Working Calendar in their user account page.
With this data in place, Polarion takes over and automatically builds a project plan which is displayed in the form of a GANTT chart in the Dashboard topic and the Live Plan view of the Work Items topic. There you can immediately see if the project looks realistic to complete in the time points, and who is over or under-tasked in what time frame, and you can make adjustments to mile stones, time estimates, etc. before the project is even up and running. As team members resolve Work Items during the course of the project, the Live Plan is updated automatically, and you can always tell if the project is on track, lagging behind, or at risk of getting bogged down in the near future.
You should be sure to read the sections in this chapter on project planning. Some aspects of the Live Plan project planning engine are configurable, so you may also want to have a look at Administrator's Guide: Configuring Planning. If you have stakeholders who use Microsoft Project, or you have a project defined with that tool that you want to import into Polarion, see User Guide: Importing from Microsoft Project and Exporting to Microsoft Project.
Last but not least in the list of things to consider when getting ready to launch a new project is Notifications. These are configured globally and the scheme is inherited by new projects. In most cases your system's global default scheme will do to begin with, and if you find that you need project-specific tweaks, you can modify the project configuration after the project is under way. For example, if you find that under the global notification scheme some notifications are not really necessary in the context of your project, you can reconfigure the notification scheme in the project scope. If some notifications are of vital importance, then you should review the global notification scheme (open Repository, then Administration > Notifications > Targets - global administrator permissions required for access), and if you find that you need to make changes for your project, perform the configuration in the same Administration topic of your project.
For more information see Administrator's Guide: Notifications, Events, and Targets.