Dans les exemples ci-dessus, la première capture d’écran (de gauche à droite) montre 4 utilisateurs avec le document ouvert, la deuxième capture d’écran montre juste un seul utilisateur avec le document ouvert, et la dernière capture d’écran montre qu’il n’y a pas de connexion au service de notification de collaboration (ou bien qu’il est hors ligne).

Cette vidéo est une démo de la fonction notification de collaboration en action avec quatre utilisateurs travaillant en parallèle sur le même document.
 

Amélioration des conflits et fusions

Pour compléter la fonction de notification de collaboration présentée précédemment, nous avons également apporté quelques améliorations aux LiveDocs quand des modifications simultanées sont effectuées.

Tout d’abord, nous avons optimisé la façon dont Polarion gère la fusion automatique de changements structurels en simultanés par différents utilisateurs : Ceci porte sur le déplacement, l'indentation, l'ajout ou suppression d’éléments, de titres et de paragraphes dans le  document. Supposons que plusieurs utilisateurs réorganisent des éléments dans différentes parties du Document. Cela ne se traduit plus par un conflit auparavant  difficile à gérer, maintenant Polarion est en mesure de fusionner en toute sécurité de tels changements. En outre, lors de la déclaration d’un conflit, Polarion indique les changements simultanés, le type de conflit (de nature structurelle par rapport aux changements de contenu). Cela aide les utilisateurs à mieux comprendre le conflit signalé.

De plus, l’avertissement de modifications simultanées a été revu. Comme nous l’avons mentionné, le type de conflit signalé est amélioré. Mais, vous remarquerez également la coloration rouge et jaune distincte pour indiquer si Polarion peut fusionner en toute sécurité les changements ou non.  Le jaune signifie que la modification simultanée peut être fusionnée en toute sécurité, mais il est recommandé à l’utilisateur d’examiner la modification avant d’enregistrer le document. Rouge signifie que les modifications simultanées sont en conflit « dur » qui se traduira par une fusion risquée où une modification antérieure sera écrasée, l’utilisateur sera alors tenu de fusionner manuellement toutes les modifications pertinentes.

Enfin, nous avons ajouté des outils explicatifs pour mieux aider à comprendre l’implication des conflits, où les utilisateurs ont apporté des modifications, et pour améliorer l’enregistrement des logs lorsque des changements simultanés se produisent.

Exemple : Modifications structurelles simultanées détectées lorsque Polarion peut fusionner en toute sécurité les modifications lors de l’enregistrement.

Exemple : Modifications simultanées du contenu détectées lorsque Polarion ne peut pas fusionner en toute sécurité les modifications lors de l’enregistrement. Si l’utilisateur enregistré le document, certains contenus seront écrasés, et l’utilisateur devra fusionner manuellement toutes les modifications antérieures. Notez également dans cet exemple qu’il y a  également eu des modifications structurelles apportées au Document, mais que celles-ci peuvent être fusionnées en toute sécurité.

Authentification des utilisateurs

Les méthodes d'authentification ont fortement évoluées dans cette nouvelle version afin d'apporter plusieurs avantages à nos clients et rendre uniforme la configuration des différents fournisseurs.

le principal bénéfice de cette approche est de pouvoir s'appuyer simultanément sur plusieurs fournisseurs et configurer Polarion de manière à ce que différents utilisateurs puissent se connecter avec différents fournisseurs. Cette fonctionnalité lève des restrictions et apporte de nouvelles options à nos clients :

• Inviter les fournisseurs et clients à se connecter à leur instance Polarion pour revues et collaborations, en permettant d'authentifier les utilisateurs externes par leurs fournisseurs d'identité respectifs,
• Utiliser plusieurs serveurs LDAP pour les authentifications,
• Créer localement des comptes utilisateurs de service permettant de se connecter à Polarion via des outils externes (sans avoir à les ajouter dans le système de gestion d'identité de l'entreprise)

Voici quelques améliorations apportées par ce nouveau mécanisme :

• Les administrateurs gardent un contrôle plus important sur le comportement de chaque fournisseur ou leur configuration LDAP respective, e.g. la fonction  auto-create peut être activée uniquement pour des méthodes d' authentification données,
• L'authentification est configuré par une page d'administration Authentication administration avec un éditeur syntaxique  XML ayant des fonctions de validation poussées qui aident à configurer proprement les authentifications,
• Les mises à jour des certificats de cryptage pour le Single Sign-on SAML sont désormais transparentes. Polarion supporte désormais plusieurs certificats pour un unique SAML authentication provider, ce qui vous permet de mettre à jour à l'avance votre certificat expirant prochainement,
• Les mots de passe  LDAP-bind  et les clients secrets oAuth peuvent être stockés en toute sécurité dans le user account vault où ils sont cryptés,
• Les clés Account vault peuvent être mises à jour par les Web Services API. Ceci permet aux équipes IT d'utiliser leurs outils DevOps favoris pour renouveler les mots de passe des comptes de service quand ils arrivent à expiration.

 

Une reconfiguration sera nécessaire pour la plupart des installations existantes de Polarion quand vous procéderez au passage en 21 R1. Avant de mettre à jour votre environnement, merci de lire attentivement le nouveau guide portant sur les authentifications disponible sur le centre de support.

Choses principales à retenir :

• Si vous n'utilisez pas d'authentification LDAP ou SAML et uniquement le fichier passwd, la reconfiguration est simple comme expliqué dans la section sur Password.
• Une nouvelle configuration est par contre requise pour toute installation existante utilisant une authentification LDAP. Sans cette configuration, votre instance Polarion ne sera pas accessible.
• Les authentifications utilisant les précédentes méthodes pour  password, OAuth 2, et  SAML sont temporairement mais nous vous recommandons fortement de les reconfigurer via la nouvelle page d'administration.

A la place du fichier passwd, un nouveau fichier passwd_credentials stocke désormais les mots de passe locaux pour les utilisateurs locaux.  Le fichier passwd existe toujours mais est désormais exclusivement utilisé pour stocker les clés secrètes générés par le système pour les processus propres à Polarion.

• Les administrateurs qui ont fait des modifications dans ce fichier avant la 21 R1 doivent en lieu et place les porter dans le fichier  passwd_credentials.
• Si vous utilisez des services externes qui se réfèrent à ce fichier passwd, modifier leur configuration pour pointer à la place vers le fichier

​Encore une fois du fait de ce changement important, veuillez-vous référer au guide très complet sur ce nouveau mécanisme d'authentification , et si besoin nous vous invitons à nous consulter avant de procéder à la mise à jour en version 21, en particulier dans le cas d'un serveur existant s'appuyant sur LDAP..

Améliorations apportées aux connecteurs

ReqIF Auto-mapper

​Un bon nombre de nos clients utilisent les outils d’importation et d’exportation de Polarion et en particulier ceux traitant le format ReqIF. Parfois ils ont besoin d’importer des fichiers ReqIF qui contiennent plusieurs documents (ou modules…) contenant de nombreux attributs, ce qui nécessite du temps pour configurer les mapping ReqIF requis. Nous avons donc ajouté pour les importations le ReqIF Auto-mapper.

Le ReqIF Auto-mapper offre un processus en deux étapes. Tout d’abord, tous les types de Work Items contenus dans le fichier ReqIF peuvent être facilement mappés pour chaque type de Work Item Polarion :

Ensuite, une liste agrégée de tous les attributs de tous les types de Work Items ReqIF est présentée afin qu’ils puissent être mappés aux attributs Polarion :

Remarque : l’option Create missing attributes and values permet de créer un champ personnalisé pour chaque champ non mappé. Cela prend également en charge les énumérations ainsi que leurs valeurs.

Synchroniser les données de planification avec Jira

Polarion 21 R1 introduit la synchronisation automatique des données de planification entre Polarion (Planned In) et Jira (Fix versions). Cela signifie que les Plans Polarion et les Versions Jira sont automatiquement créés, mis à jour et supprimés s’ils sont référencés dans les champs Planned In ou Fix versions. La configuration est similaire au mapping de Work items :
 

Présentation des données des liens vers des systèmes intégrés à Polarion (ex. Teamcenter)

Jusqu’à présent, les attributs des Work Items liés dans les systèmes distants n’étaient accessibles qu’en survolant le lien et étaient présentés dans un aperçu. Pour faciliter les choses, nous avons
mis en place un mécanisme qui met l’information là où vous en avez besoin. Dans le formulaire du Work Item :

Dans cet exemple, une nouvelle section a été ajoutée au formulaire de Work Item. Dans cette nouvelle section, un type spécifique de Work Items liés est affiché (Demandes de modification) et pour chacun des éléments, vous pouvez afficher directement leur statut.

Le nombre de sections, les types de Work Items et les attributs à afficher peuvent être configurés. Dans l’exemple suivant, vous pouvez voir plus d’attributs configurés, comme l’utilisateur, la date, etc. :

Permissions par champ pour les LiveDocs

Afin de configurer un processus et workflow robustes pour les Documents, le schéma des permissions des LiveDocs a été amélioré avec des per-field permissions (permissions par champ).  Equivalent à la fonctionnalité existante du work item, la valeur du statut et des custom fields (champs personnalisés) peut être mise en lecture seule de façon sélective, ou entièrement masquée. Pour en savoir plus sur cette  configuration veuillez-vous référer à la section « Permission Management » sous Documents.

Les Custom sets peuvent être configurés pour refléter les différentes étapes du workflow d’un Document. Une fois que le Document a atteint un certain niveau de maturité, ses champs peuvent être verrouillés pour empêcher leur modification par des utilisateurs ne devant pas avoir les droits de mises à jour. Il est donc maintenant plus facile de réaliser les scénarios suivants :

• Assigner un unique Document ID lors de la création d’un Document qui ne devrait jamais être modifié.
• Configurer un champ de version d’un Document, qui s’incrémente seulement durant  certaines étapes de workflow par l’action d’un script, mais qui n’est pas modifiable par d’autres moyens.
• Une fois un Document approuvé, vous pouvez figer sa Version, son Propriétaire et son niveau d'évaluation des Risques
• S'assurer que des données propres à un métier, par exemple l'évaluation de la spécification par le département assurance qualité, ne puissent être éditées que par le responsable qualité

Attributs personnalisés pour les Test Records

Nos clients utilisent souvent Polarion pour gérer la vérification et la validation de leurs produits. Tester un produit ou un logiciel nécessite souvent une infrastructure et des outils spécifiques qui supportent leurs activités de tests. La gestion des Tests dans Polarion a été améliorée avec ces objectifs à l’esprit en étendant les données d’exécution de test avec des attributs personnalisés.

Les attributs personnalisés vous permettent de suivre des informations structurées supplémentaires pendant ou même avant l’exécution du test, par exemple :

• Un testeur responsable de l’exécution d’un cas de test particulier
• Numéro de série de l’équipement test utilisé pour l’essai
• Tension, température, ou débit mesuré pendant l’essai

La tenue de tels enregistrements dans un format structuré permet un contrôle et une validation des processus plus robustes pour les exécutions de tests. Il permet également de rendre compte plus facilement des données de vérification, ce qui fournit des informations supplémentaires et des améliorations potentielles de la productivité aux procédures de vérification d’un client.

Les attributs personnalisés sont configurés via une nouvelle page d’administration Test Record Custom Fields. Les attributs peuvent être remplis via la vue Test Execution, ou définis via des APIs et affichés ultérieurement sur la vue Test Records, et dans le widget Test Records.

Enfin nous vous présentons ci-dessous quelques autres améliorations significatives :

Amélioration des Collections

Les Collections étant le dernier ajout majeur à Polarion, leurs fonctionnalités continuent d’être améliorées et complétées sous  la version Polarion 21 R1 :

• Le type Collection est disponible dans la Table widget dans les Live Reports pour une sélection plus facile des Collections dans les rapports.
• Les champs personnalisés de type Enumeration sont disponibles pour les Collections. Le champ d’énumération multi-valeurs n’est pas encore disponible, à venir dans une prochaine version.
• Coller l’URL d’une Collection ou d’une Baseline dans un champ riche texte ( comme le champ description)  créé un lien direct, qui vous permet de référencer aisément vos Collections et autres artéfacts.

Amélioration de l’ergonomie

• Une action Collapse All a été ajoutée à l'onglet Document Outline, ainsi les utilisateurs peuvent aisément refermer la structure entière du document afin d’y naviguer plus facilement.
• En plus d’être en mesure d’insérer des Work Items référencés, les utilisateurs affectés à la licence Polarion QA peuvent désormais également figer  les Work Items référencés ou l'inverse ( action Freeze/Unfreeze).

Amélioration de l’administration

À partir de Polarion 20 R2, afin de faciliter le déploiement des correctifs pour les administrateurs, nous les avons transformés en mini-versions. Ils sont distribués comme Update Package complet avec leur propre build ID. Cela permet aux administrateurs de déterminer facilement la version du patch à partir de l’interface utilisateur Polarion.

Nous avons également facilité la collecte par les administrateurs des retours et commentaires des utilisateurs. Tout comme nous, de nombreux administrateurs Polarion suivent les retours et les demandes d’améliorations venant des utilisateurs dans un projet Polarion dédié. L’action Send feedback, sur le panneau Configuration, est également configurable.

Une nouvelle version de Tomcat a été introduite sur la plate-forme Polarion, qui ajoute d’autres moyens d’assurer un déploiement Polarion en toute sécurité. La communication entre Apache HTTPD et le port Tomcat AJP de Polarion peut maintenant être configurée pour nécessiter un token secret.

Amélioration des performances et de l’évolutivité

Un système rapide et réactif est essentiel pour une bonne facilité d’utilisation et à la satisfaction de l’utilisateur final. Pour cette nouvelle version 20 R1, ont été mis l’accent sur des actions spécifiques en vue d’améliorer l’interface utilisateur ainsi que les performances globales de Polarion dans trois domaines différents.

Ces optimisations ont permis :

• D’accélérer de 22% à 57% l’import initial de Documents issus de différentes sources
• D’accélérer l’import pour la fonction Document Round-trip de 15% à 31%
• D'accélérer la sauvegarde des modifications dans un LiveDoc de 13% à 38%
• d'accélérer les opérations d’écriture de 26% à 36% lors de tests de charge portant sur 2000 utilisateurs travaillant en simultanés sur un repository contenant 10 millions de Work Items

Si ces améliorations ou nouveautés vous intéresse n’hésitez pas à passer en version 21 R1 dès à présent, quelle que soit votre version actuelle installée.

Pour plus d’informations accédez aux détails de la couverture des versions et services releases de Polarion ALM sur le Polarion Blog.

Depuis la version 19.2 de Polarion, il est possible de créer des Baselines de Documents, permettant ainsi de capturer et rendre plus accessible toute version ou révision de la spécification. Il est d'usage de créer une Baseline à chaque approbation d'une version du document.

Cet article n'a pas pour objet de présenter comment créer une Baseline, vous trouverez dans l'aide en ligne toutes les informations nécessaires. Notez juste qu'une Baseline peut être créée même sur des versions de documents datant de plusieurs années (on peut trouver cela intéressant pour rendre plus lisible son historique).

Note : On entend parfois qu'une Baseline "fige" une version du document, cela n'est pas vraiment exact car une révision historique d'un document est intrinsèquement figée, il est plus juste de dire qu'une Baseline pose un marqueur, qualifie une révision du document et en facilite son accès.

Baselines de documents et signatures électroniques

Note : Cet affichage se fait par un Wiki Content, tout comme cela est fait avec Document Properties.

Si le script correspondant vous intéresse, merci de nous contacter et nous vous ferons parvenir la macro.

Créer des Baselines de documents à chaque version c'est bien, le faire automatiquement c'est mieux !

Avoir des Baselines de documents permet d'alimenter la Collection bien plus aisément que de devoir "piocher" dans des listes de révisions.  Ainsi lors de la sélection du document à mettre dans la Collection, nous pouvons afficher et sélectionner la liste des Baselines de documents.

Nous avons alors une Collection qui pointe vers une Baseline donnée de chaque document de la Collection, spécifications d'exigences clients ou systèmes, spécification des tests et des risques, etc.

Quand l'auditeur ou l'utilisateur naviguera dans la Collection mise à disposition,  il lui sera facilement proposé les documents présents dans la Collection, dans la version « baselined » désirée (notez que dans notre exemple nous avons même créé une Baseline de la Collection).

Au final, une préparation de l'audit rendue plus simple et également  une réalisation de l'audit qui va à l'essentiel !

En conclusion si vous utilisez les LiveDocs de Polarion, n'attendez plus et développez l'usage des Baselines de documents (ou de LiveDocs). Il faut ajouter une pincée d'automatisation pour rendre leur utilisation plus fluide. Contactez-nous et nous vous fournirons les briques nécessaires.