Newsletter octobre 2023

La nouvelle version Polarion ALM 2310 est disponible

Cette version majeure de Polarion apporte de nouvelles fonctionnalités et des améliorations de fonctionnalités existantes, notamment en terme de productivité, de sécurité et convivialité pour les utilisateurs, entre autres :

• Le Bulk Branching - amélioration de la création de branches en masse pour un développement rationalisé
• La gestion hiérarchique des permissions d’espace - renforcez les contrôles d’accès aux espaces et choisissez les équipes qui peuvent afficher ou modifier leur contenu
• L’amélioration de la collaboration sur les Rich Pages
• La configuration optimisée des étapes de test
• L’amélioration l’expérience utilisateur, en particulier avec les diagrammes Interactifs - liez de manière contextuelle les éléments des diagrammes (UML, SysML…) aux work items Polarion et naviguez entre eux
• Avancée de l'ouverture grâce à l’API REST

Intéressons-nous plus en détails à ces nouveautés la version 2310 de Polarion.

Bulk Branching - Création de branches en masse

Cette nouvelle fonctionnalité rend plus efficace la réutilisation et le développement en parallèle par la création de branches en masse ou Bulk Branching , elle vous permet de créer plusieurs branches de documents en une seule opération. Points Clés :

1. Bulk Branching : Vous pouvez rapidement et facilement créer des branches de documents ou des copies de plusieurs documents tout en maintenant des liens relatifs, facilitant ainsi les transitions dans votre processus de développement.
2. Liens entre Documents : Les documents copiés sont liés à leurs documents sources via le champ « branched from », préservant les liens entre eux. Les work items copiés sont également liés à leurs items sources via le lien « branched from », permettant une gestion et un suivi efficace des liens entre work items.
3. Comparaison et Fusion de LiveDocs : La fonctionnalité Bulk Branching constitue la première brique de la fonctionnalité de comparaison et de fusion auto-merge prévue avec la prochaine version de Polarion. Cela vous permettra de travailler de manière encore plus collaborative avec plus d’automatisme sur les documents réutilisés.
4. Création de JavaScript personnalisé : Polarion propose un moyen rapide de créer un JavaScript pour les documents sélectionnés pour un Bulk Branching. Ce script peut être utilisé sur une page pour répéter la même opération de création de branches en masse en conservant le même paramétrage.

Workflow simplifié :

• Brancher plusieurs documents en une seule fois : Effectuer un Bulk Branching en une seule étape permet de réduire les actions répétitives et de gagner en productivité
• Personnalisation : Définissez un projet cible commun, un espace cible, un pattern de nommage et un filtre pour tous les documents ou adaptez ces paramètres pour chaque document, individuellement.
• Surcharge des work items : Surchargez si besoin les work items référencés dans les documents réutilisés pour les aligner sur vos besoins en développement.
• Préserver les liens relatifs : Maintenez l'intégrité des liens relatifs entre l'ensemble des documents réutilisés tout en surchargeant les work items.
• Workfows et signatures : selon vos besoins, décidez si vous devez copier ou réinitialiser le workflow et les signatures.
• Champs des work items : Définissez quels champs des work items doivent être réinitialisés lors de la réutilisation d’un document, vous donnant ainsi un contrôle complet sur le processus de création de branches.

Avec le Bulk Branching , Polarion 2310 permet de dupliquer aisément plusieurs documents et d'exploiter pleinement le potentiel des capacités de réutilisation et de développement parallèle dans vos projets.

Gestion hiérarchique des permissions d'espace

Dans Polarion 2310, l'une des fonctionnalités importantes et attendues est l’introduction d’une gestion hiérarchique des permissions portant sur les espaces, c’est-à-dire les dossiers qui contiennent les documents ou pages, vous permettant par exemple de maintenir la confidentialité des données critiques tout en assurant une collaboration efficiente. Cette évolution offre une personnalisation des permissions à un niveau plus fin pour chaque espace et pour les artefacts qui y sont contenus et facilite la gestion des accès à l’espace par son propriétaire. Points Clés :

1. Assurance de la confidentialité : Grâce à cette fonctionnalité, vous savez que seules les personnes autorisées ont accès aux documents et informations confidentielles. Les sous-espaces et les artefacts héritent des autorisations de leur espace parent, excepté si des permissions explicites ont été ajoutées aux sous-espaces.
2. Contrôle des modifications et des suppressions : Vous pouvez contrôler qui peut modifier ou supprimer des fichiers au sein d'un espace, réduisant ainsi le risque de modifications accidentelles pouvant compromettre l'intégrité des données.
3. Permissions personnalisées : tout détenteur d’espace ayant la capacité de gérer les permissions peut désormais adapter les permissions de l’espace à ses besoins spécifiques. Cette facilité vous permet de personnaliser les accès pour les utilisateurs, groupes ou rôles de votre organisation.
4. Permissions granulaires : Polarion 2310 vous permet de configurer différentes permissions pour les espaces et les artefacts qu'ils contiennent. Ces permissions comprennent :

• Can View : Les utilisateurs peuvent consulter les espaces, les pages et les documents, y compris les work items qu'ils contiennent (à condition d'avoir l'autorisation de lecture sur les objets eux-mêmes),
• Can Edit : Les utilisateurs ont la permission de créer, de modifier et de lire le contenu des espaces et de tous les artefacts qu'ils contiennent,
• Own the Space to Manage It : Les utilisateurs ayant cette permission peuvent gérer les accès, contrôler les permissions utilisateur au niveau de l'espace et si besoin en modifier le titre et la page d'accueil,
• Deny Access : Cette permission restreint l'accès complet à la lecture de l'espace, des pages, des documents et de tous les work item contenus dans l'espace.

Cette nouvelle amélioration garantit que vous avez un contrôle total sur qui peut accéder, modifier ou gérer les espaces et les artefacts au sein de Polarion 2310, offrant une sécurité renforcée et une personnalisation accrue pour mieux répondre aux besoins des équipes.

Porter la Collaboration sur les Rich Pages

La fonctionnalité "Collaboration sur les Rich Pages" a été grandement améliorée en vous apportant des outils pour gérer la revue et commenter le contenu des Rich Pages, facilitant ainsi la capture des feedbacks sur la page, données présentées et les prises de décisions. Points Clés :

1. Revue et fils de discussion : Cette fonctionnalité permet simplement aux utilisateurs d’enregistrer des commentaires, de reporter des anomalies, donner des suggestions d’amélioration, pour une plus grande contribution et une meilleure interaction avec les équipes produits en charge de la page.
2. Résolution de commentaires : Simplifiez la collaboration en résolvant les commentaires des Rich Pages après la prise en compte des retours. Cela garantit une communication claire et un suivi des progrès au sein de vos projets.
3. Suivi des pages : Restez informé sur les évolutions des pages qui comptent le plus pour vous en devenant "Watcher". Ceci vous permettra d’être notifié des mises à jour ou de nouveaux commentaires et ainsi participer activement à l’amélioration des outils à disposition.
4. Mises en évidence des modifications : Suivre les changements sur les pages n'a jamais été aussi simple. Une nouvelle fonctionnalité de comparaison met en évidence les modifications dans le contenu des pages, ce qui permet de mieux identifier les mises à jour importantes et même les changements portant sur les lignes de scripts utilisés dans les Rich Pages

Bonus : Contrôlez l'Éditeur de Rich Pages via des Raccourcis Clavier En bonus, l'éditeur de Rich Pages a été amélioré avec un nouvel ensemble de raccourcis clavier, rendant l’interaction avec les Rich Pages plus efficace et intuitive. Avec les nouvelles fonctionnalités de collaboration sur les Rich Pages vous suivez et maitrisez mieux les évolutions des pages, vous êtes plus proactifs dans leur conception et les prises de décision sont plus interactives, dynamiques et facilitées.

Etendue des étapes de test

Polarion 2310 permet d’adapter la configuration des étapes de test pour s’adapter à la typologie et la définition des différents cas de tests. Points clés :

1. Présentations personnalisées : Configurer des définitions distinctes des tableaux d'étapes de test pour chaque type de work item représentant un cas de test
2. Notification de mise à jour : Désormais les testeurs peuvent repérer instantanément les étapes de test ayant une définition non à jour. En mode édition, un ruban jaune apparaît si la représentation des étapes de tests ne correspond pas à la configuration actuelle pour ce type de work item.
3. Transition fluide : Cliquez sur le bouton de mise à jour du ruban pour ouvrir le work item dans un onglet séparé en appliquant la définition la plus récente.

Si vous souhaitez effectuer une modification en masse de vos étapes de test vers la nouvelle configuration, un outil de mise à jour en masse des étapes de test est disponible sur le site des extensions Polarion : Test Steps Bulk Updater tool

Avec Polarion 2310, cette configuration sur mesure des étapes de test permet de mieux prendre en compte les spécificités de chaque type de test en terme de définition et d’exécution de ces tests

Amélioration de l'Expérience Utilisateur

Nous dévoilons ici des améliorations de Polarion 2310 qui mettent l'accent sur l’optimisation de l'utilisabilité de l’outil et par la même son efficacité , ceci en prenant en compte de nombreuses demandes de clients. Autrement dit, simplifier l'expérience utilisateur afin d’en faire davantage en moins de clics !

Interactivité des Diagrammes Améliorée Dans Polarion 2310, l'éditeur de diagrammes offre la possibilité de créer des diagrammes interactifs. Ces diagrammes permettent de lier des éléments de diagrammes à des work items Polarion ou à des références externes, ce qui permet à l’utilisateur de naviguer aisément entre eux. Des liens peuvent être ajoutés au canevas ou à des formes spécifiques. Bien que ces liens améliorent l'interactivité, ce ne sont pas des live links et de ce fait, ils ne se mettront pas à jour lorsque la source changera (les liens sont inactifs en mode prévisualisation et lors de l'export aux formats PDF ou docx).

Amélioration de l’Editeur de LiveDocs Dans Polarion 2310, l’éditeur de documents a fait l’objet d’évolutions significatives pour améliorer votre expérience de création et de personnalisation de documents. Voici les deux améliorations notables : Présentation du work item avec uniquement son titre La configuration pour présenter un work item dans un LiveDoc inclut désormais une option « Titre uniquement ». Ceci permet une présentation plus concise des données, notamment pour les documents volumineux contenant de nombreux work items.

HTML Snippet Injector L’éditeur de document prend désormais en charge la, fonctionnalité « HTML Snippet Injector », au même titre que ce qui est déjà disponible pour le bandeau de navigation ou la page de login. Ceci vous permet de personnaliser encore plus l’interface utilisateur du document. Pour obtenir un exemple concret, reportez-vous sur la page dédiée des extensions Polarion. Liens hypertexte simplifiés à l’export PDF Vous souhaitez exporter votre spécification au format PDF afin de la remettre à votre client, mais vous ne voulez pas que s’il clic sur une exigence ça le renvoie vers votre serveur Polarion ! Vous pouvez désormais aisément supprimer ces liens du PDF exporté ! Points Clés :

1. Configuration personnalisée des liens hypertexte : Dans la boîte de dialogue « Export to PDF », une nouvelle option de configuration « Hyperlinks» est disponible.
2. Suppression par défaut des liens Polarion : l’option par défaut « Remove Polarion links» garanti que seuls les références croisées et liens externes restent dans le document PDF.
3. Options additionnelles : les utilisateurs peuvent choisir entre « Keep all links», ce qui conserve le comportement habituel de Polarion, et « Remove all links», qui suppriment tous les liens hypertexte du document PDF.

Cette amélioration qui simplifie le processus d’exportation PDF permet d’adapter vos documents à une audience externe tout en conservant clarté et fonctionnalité.

Améliorations apportées à l’éditeur Rich Text Dans Polarion 2310, l’éditeur de texte intègre deux améliorations significatives pour rendre la création de contenu encore plus conviviale Références de pièces jointes en Rich Text Vous pouvez désormais coller facilement des liens esthétiques vers des pièces jointes directement dans votre document Rich Text. Cela ajoute des labels explicites avec des icônes pour les liens des pièces jointes. Sont pris en charge les pièces jointes liées aux Work Items, aux Pages, aux Modules et aux Test Runs, ainsi qu’une icône d’horloge et une info-bulle de révision pour les liens de Baseline.

Réutiliser les couleurs récentes L’éditeur présente désormais jusqu’aux dix dernières couleurs utilisées par chaque utilisateur pour les polices et les arrière-plans de police. Ces couleurs sont stockées dans les préférences de l’utilisateur et sont accessibles à partir de n’importe quel éditeur Rich Text de Polarion. La barre d’outils est enrichie des dernières couleurs utilisées qui sont affichées sous la palette de couleurs disponibles.

Avancée de l'ouverture grâce à l’API REST

Polarion continue de renforcer son ouverture en étendant la couverture de son API REST. Bien que nous n'entrerons pas dans les détails ici, les domaines suivants ont vu des améliorations significatives :

• Gestion des tests : Support des différentes activités de test, actions CRUD (Créer, Lire, Mettre à jour, Supprimer) sur les objets Test Run, importation et exportation des résultats des cas de test. Notez que l'exécution des tests utilisant un contexte d'exécution sécurisé n'est pas prise en charge par l’API REST.
• Gestion de projet : création, mise à jour, déplacement, marquage et suppression de projets
• Plans : lecture, création, mise à jour, et suppression des objets « Plan » et « Plan Template», facilitant ainsi la planification des projets.
• Révisions : Support de la lecture des informations de révision, avec l'auteur et messages du commit.
• Work Item : Nouvelles opérations CRUD pour les Work Items, avec la mise à jour de Work Records, la lecture des Work Items avec les backlinks, l'accès aux actions de workflow, les conversions de type, et bien plus encore.

Pour plus d’information veuillez consulter la documentation de référence dans le dossier SDK et le guide de l'utilisateur des API REST . Ces améliorations renforcent la capacité de Polarion à se connecter de manière transparente à d'autres outils, assurant une chaîne de production cohérente et efficace.

Autres évolutions :

Accès simplifié aux données avec PostgreSQL Le schéma de la base de données PostgreSQL a évolué et permet désormais de lire les données liées aux tests, étapes de tests, et résultats par des requêtes SQL plutôt que de s’appuyer comme aujourd’hui sur les APIs pour concevoir des rapports et indicateurs. Des exemples de requêtes sont fournis dans la documentation. Authentification améliorée Peut-être avez-vous déjà été confronté à un changement de votre ID de compte LDAP ou oAuth2 , avec pour conséquence un compte utilisateur Polarion qui n’est plus en phase, et l’obligation de créer un nouvel utilisateur Polarion ? Ce dernier point reste vrai, mais vous pouvez associer l’ancien compte et votre nouveau compte pour continuer à retrouver et gérer vos éléments de gestion. Mises à jour du guide de déploiement et de maintenance Pour assurer un processus de déploiement et de maintenance réussi, les mises à jour et améliorations suivantes ont été apportées :

• Amélioration des conseils pour le réglage des caches SVN afin d’optimiser les performances
• Réglage des ressources système - comment réajuster le système après l’augmentation des ressources système afin de garantir des performances efficaces
• Procédures opérationnelles - afin de faciliter le déploiement et la maintenance de Polarion, les procédures opérationnelles et conseils pour l’archivage des projets sont désormais documentés

Enfin pour d’avantage d’information sur les évolutions et corrections apportées par cette nouvelle version Polarion ALM 2310 nous vous invitons à vous rendre sur le Polarion Blog .

Votre prochaine formation à Polarion

Vous avez peut-être déjà fait appel à Polarsoft pour vous former et vous accompagner dans votre premier déploiement de Polarion. Nombreuses sont aussi les demandes pour former un nouvel utilisateur, un référent sur la solution Polarion ou encore pour une formation avancée afin d’exploiter au mieux le potentiel de l’outil.

Nous vous proposons des formations adaptées au besoin de chacun qui sont dispensées en intra-entreprise (sur site client ou en distanciel) et inter-entreprises organisées dans nos locaux à Saint-Quentin-en-Yvelines, ou en distanciel.

Découvrez ici nos différentes formations avec leur programme ainsi que les dates des prochaines sessions inter-entreprises à Saint-Quentin-en-Yvelines, ou cliquez directement sur celles vous intéressant plus particulièrement programmées prochainement :

• Polarion REQUIREMENTS Utilisateur : du 20 au 21 novembre (session en distanciel)
• Polarion ALM Utilisateur Avancé & Administrateur : du 4 au 5 décembre (session en distanciel)

Si vous ne trouvez pas dans ces programmes la réponse à votre besoin en formation nous pouvons vous proposer une formation ciblée sur vos attentes (ex. Polarion Utilisateur adapté à votre contexte, Ingénierie des exigences, Ingénierie système…), n’hésitez pas à nous en faire la demande !

Une nouvelle intégration Polarion dans le domaine du test avec Yest

La solution de conception et d’implémentation des tests fonctionnels Yest de Smartesting dispose désormais d’un connecteur pour Polarion. Yest apporte une solution aux équipes de test et de validation qui souhaitent :

• Réaliser des gains de productivité en automatisant votre chaîne de test de bout-en-bout, depuis la conception jusqu’à l’exécution,
• Mettre en œuvre des approches agiles, collaboratives, et « shift-left » avec documentation vivante, type ATDD/BDD.

Yest s’interface avec Polarion :

• En amont pour référencer les exigences et préparer la traçabilité avec les tests qui seront produits
• En aval pour exporter les tests dans Polarion, incluant les étapes de test et les liens de traçabilité

• Depuis Yest, consultation du projet Polarion et références aux exigences par simple drag & drop
• Publication des scénarios de test Yest en tests Polarion avec les liens de traçabilité des exigences
• Maintenance des tests Polarion directement dans Yest et mise à jour par une nouvelle publication

Yest permet aussi :

• la création graphique des parcours applicatifs,
• l’ajout de tables de décision sur les principales actions du parcours,
• la production de scénarios de test de façon assistée et par génération automatique,
• la visualisation de la couverture des différents critères choisis,
• l’export des tests dans un outil tiers de management des tests comme Polarion QA en vue d’une exécution manuelle de ces tests,
• l’export des scripts dans le langage de script et dans l’environnement d’exécution automatique choisis,
• la définition et la combinaison des jeux de données de test

Vous souhaiteriez voir une démo de l’intégration Polarion - Yest ? N’hésitez pas à nous contacter directement ! Pour plus d’information sur Yest : https://www.smartesting.com

Nos événements & webinaires à venir

Nous aurons le plaisir de présenter lors d’un prochain webinaire comment simplifier et fiabiliser la validation de vos SI avec la méthodologie GAMP® 5 et Polarion. Ce thème intéressera toutes les parties prenantes qui ont le besoin de valider leurs systèmes informatisés conformément aux réglementations applicables à leur domaine métier, GAMP® 5 étant une référence qui sert d’inspiration pour bon nombre entreprises, en particulier dans le secteur du pharmaceutique.

Alors si vous êtes concerné par cette problématique assistez à ce webinaire en vous inscrivant ici.

Pour connaître nos futurs événements et vous y inscrire à nos prochains webinaires rendez-vous sur notre page Evénements .

Nos avis, conseils et recommandation d’experts

Cette rubrique a pour but de vous apporter quelques trucs et astuces pour faciliter votre quotidien avec Polarion. Ces conseils proviennent des experts Polarsoft mais aussi de l’écosystème Polarion France : clients, partenaires, consultants que nous encourageons vivement à nous faire part de leurs conseils, astuces et autres avis pour une prochaine publication ! L’article de cette newsletter couvre la réutilisation de vos spécifications, et comment gérer des variantes avec la gestion de branches . La nouvelle fonctionnalité de Bulk Branching délivrée avec la version 2310 de Polarion ALM nous permet de revenir sur un principe de réutilisation de documents et donc de Work Items que nous avons déjà abordé en avril 2018 avec la fonctionnalité de merge ( https://www.polarsoft.fr/Newsletter/fiche/id/2#trucs-astuces-exploiter-polarion-alm ), à savoir la gestion des branches. Tout d’abord pour lever toute confusion car nous utilisons ci-dessus le terme réutilisation , nous n’allons pas développer la fonctionnalité reuse de Polarion, que nous avons déjà développé en octobre 2021 ( https://www.polarsoft.fr/Newsletter/fiche/id/16#nos-trucs-astuces ), et oui, créer une ou des branches est aussi une forme de réutilisation ! Les développeurs qui s’appuient sur des gestionnaires de code source (Subversion ou Git par exemple) connaissent bien le principe de branches : créer une branche consiste à diverger de la ligne principale de développement (le master ) et à continuer à travailler sans impacter cette ligne. Pour cela, ils travaillent dans une branche, et le moment venu où le code de la branche est validé, le contenu de la branche est poussé, fusionné vers le master. C’est ce même principe que nous allons appliquer sous Polarion ALM, non avec du code mais avec des documents de spécifications et les Work Items contenus ou référencés dans ces documents afin de gérer notamment des variantes de spécifications. Pour simplifier notre propos, nous parlerons de spécifications d’exigences et/ou de tests pour un produit X, mais cela s’applique bien entendu à tous types de documents ou tous types de Work Items.

Quand on pense branche principale ou master, on peut comprendre la spécification d’exigences génériques applicable au produit présent au catalogue, donc les exigences qui s’appliquent à un produit standard sans adaptations réalisées particulièrement pour un client, ou pour produire un produit dérivé avec des fonctions étendues. Sous Polarion, on trouve donc un LiveDoc qui contient ces exigences de base. Ce document de spécification va suivre un cycle de vie, être revu, être approuvé pour une version donnée, disons la version 1.0. Nous pourrions alors créer une nouvelle version de cette spécification, mais peut être voudrions-nous laisser ce document dans son état actuel (par exemple pour ne pas impacter la ligne principale) et au contraire initier les évolutions de la version 1.1 sur un autre axe de spécification, à savoir une branche. En reprenant notre exemple de produit adapté spécifiquement pour un client, nous pouvons aussi considérer de créer une branche qui va s’appuyer sur cette spécification générique, puis en modifier le contenu pour adresser cette nouvelle ligne de conception. Ainsi, le document de spécification Master reste la référence pour le produit standard sur catalogue, là où les branches portent les spécificités des produits adaptés ; on parle souvent de variantes. Un des avantages de la gestion des branches est qu’elle permet de réutiliser, sans réécrire, sans dupliquer - en tout cas pour les exigences qui ne changent pas. Entrons dans le vif du sujet de la branche pour expliciter toute cette théorie !

Une branche en lien avec le Master
​
Quand on regarde les propriétés d’une exigence du Master qui se trouve dans une ou des branches, on peut lire que l’exigence est contenue dans ce document et référencée dans un ou plusieurs autres documents.

A l’inverse, quand on regarde cette même exigence dans l’une ou l’autre des branches, on peut lire que l’exigence est référencée dans ce document, potentiellement référencée dans d’autres et contenue dans un autre (un et un seul !)

Notez le trait vertical discontinue sur le côté gauche de l’exigence dans le document branche, cela signifie que l’exigence est ici référencée :

Ceci à pour conséquences :

• Cette exigence n’est pas modifiable dans la branche, en tout cas pas cette exigence avec cet identifiant d’exigence (DP-3943)
• Suivant le choix retenu lors de la création de la branche, cette exigence dans ce document se verra présentée, ou pas, avec les changements opérés dans le document Master. Dit autrement (vite un exemple car cela se complique !), si je passe la vitesse de 40 km/h à 50 km/h dans le document de référence, je verrai aussi 50 km/h dans la branche car l’exigence est la même dans les deux documents, ce n’est pas une copie, c’est une référence.
• Mais comme nous l’avons dit, c’est un choix de suivre ou pas ces changements : nous changeons la vitesse de 40 à 50 km/h pour la prochaine version du produit, mais pour notre client, ce sera toujours 40 km/h, donc la branche correspondante ne doit pas hériter des changements de la ligne principale. Dans ce cas, c’est toujours la même exigence, c’est toujours une référence, mais une référence sur une version (révision) donnée de l’exigence. On dit alors que l’exigence est figée dans la branche.

Mais au fait, comment créons-nous une branche ? Jusqu’en version Polarion 2304, il y avait deux façons de créer une branche, à savoirà partir du document principal, invoquer la fonction Branch, nommer le document cible et renseigner son futuremplacement, et surtout donner la révision à partir de laquelle la branche va être créée .

Ce choix de la révision a un impact notable, à savoir que :

• Si la branche s’appuie sur la révision Head, alors elle suivra les évolutions du document principal
• Si la branche est faite à partir d’une révision donnée du document principal, alors les exigences de la branche seront figées sur cette révision

Ceci nous renvoie à la question du choix du suivi des changements évoquépréalablement. Autre façon de procéder : partir de l’historique du document, naviguer vers une baseline dece document, puis actionner la création de la branche à partir de là, par rapport àl’approche précédente ceci facilite le choix de la révision.

Et si je veux faire une branche sur un ensemble limité d’exigences ? Apport important par rapport à la fonction Reuse , une branche peut être créée ens’appuyant sur un document filtré par une requête standard de Polarion afin, dès lacréation de la branche, de ne cibler que les exigences désirées. Et maintenant le Bulk Branching Nous ne rentrerons pas dans le détail ici de cette nouvelle fonctionnalité car vous pouvez en voir tousles avantages dans notre rubrique présentant les nouveautés de Polarion 2310. Nous pensonssimplement que cette fonction va fortement contribuer à une plus grande utilisation du mécanisme debranches dans Polarion, voire remplacer avantageusement la fonction reuse , y compris le reuse dedocuments multiples.

La branche existe, que faisons-nous maintenant avec nos exigences référencées Pour rappel, nos exigences référencées sont celles qui sont dans la branche ! Nous pouvons faireface à plusieurs cas dans ce document :

• Une exigence ne s’applique pas pour cette variante, alors supprimons-la de la branche (remove)
• Une nouvelle exigence, qui n’existait pas auparavant, s’applique à cette variante, alors créons là comme nous savons le faire pour tout Work Item. Ceci conduit à ce que dans la branche, nous ayons des exigences référencées et des exigences propres à cette variante qui cohabitent.

• Une exigence déjà existante évolue, nous devons créer une nouvelle exigence, la surcharger (overwrite). Ceci revient à dupliquer l’exigence mais n’oublions pas que les autres exigences restent en référence, donc nous ne faisons évoluer que ce qui change.

Et voici le résultat de l’ Overwrite , une nouvelle exigence avec un nouvel identifiant, qui estdonc modifiable et détachée du document principal , donc si l’exigence deréférence change, cette exigence ne change pas.

Autre résultat notable de cette surcharge, un lien is branched from est automatiquementcréé, ce qui nous permet de bénéficier de la traçabilité entre exigences,d’utiliser les liens suspects et si besoin de faire une fusion entre l’exigence qui est dans la branche etl’exigence qui est dans le master ! Pour ceci, nous vous renvoyons à la newsletter d’avril 2018 . Ce lien sera aussi très certainement usité quand la nouvelle fonctionnalité d’ Auto Merge sera prochainement disponible, stay tuned ! Autres fonctionnalités en vrac Ce principe de branches s’accompagne de nombreuses autres fonctionnalités ou moyens que nous n’allonspas développer ici, qui servent surtout à faciliter la gestion de ces branches multiples vis-à-visde la spécification principale :

• Fonction de comparaison entre master et branches et entre branches, et fonction de merge (voir newsletter d’avril 2018)
• Fonction de freeze/Unfreeze d’une exigence ou d’un ensemble d’exigences : vous avez modifié une exigence générique, la branche est figée sur une version et vous voulez prendre en compte ce changement : faire un unfreeze ou un freeze sur la nouvelle révision désirée pour mettre à jour vos exigences dans la branche
• Construire des vues permettant de représenter l’architecture des documents principaux et branches, par exemple :

Des remarques fréquentes de nos utilisateurs : 1. Je n’ai jamais utilisé la fonction Branch pourtant j’ai des exigences en référence

Oui, c’est effectivement possible ! On ne parlera pas alors vraiment de branche, car une branche se fait globalement au niveau d’un LiveDoc. Cependant lors d’un copier/coller d’une ou plusieurs exigences d’un document à l’autre (voire de la vue table à la vue document), on se voit proposer de mettre en référence ces exigences dans le nouveau document ! C’est également un moyen efficace, lorsqu'on a déjà créé une branche et qu’une nouvelle exigence arrive dans la branche principale, de la propager dans la branche, ou l’inverse. 2. J’ai créé une branche mais je n’ai pas de lien entre mon exigence référencée et l’exigence dans le document principal Oui, le lien is branched from n’est créé que quand on fait un overwrite de l’exigence référencée, car sinon cela reviendrait à faire un lien sur soi-même ! 3. Si je ne fige pas ma branche sur une version donnée du document Master, rien ne m’indique qu’une exigence référencée a été modifiée dans ce document principal C’est exact, car le document branche ne change pas, il n’y a pas de nouvelles versions de ce document, donc le changement arrive, devient visible mais rien ne l’indique notablement. Sachez qu’il existe des moyens de tracer ces changements par l’utilisation de scripts wikis, mais le mieux et le plus simple est sans doute de mettre en place un suivi des changements au niveau du master. En conclusion Développer une première version sous Polarion d’une spécification d’un produit est une chose, la faire évoluer, avec des versions multiples, avec plusieurs variantes ou cibles et par des équipes multiples en est une autre. La gestion de branches « à la mode Polarion » permet de répondre à ces enjeux. Certes, il peut paraître plus simple de faire plus simplement du reuse avec traçabilité, en dupliquant les documents et leur contenu, mais ceci n’a de pertinence que si l’on découpe ses variantes au sein de plusieurs projets. Si l’on désire rester dans le cadre d’un seul et unique projet, il nous semble que la gestion de branches, avec en particulier les nouvelles fonctionnalités apportées par la version 2310 et celles à venir, soit l’approche la plus pertinente et la plus performante ! Nous espérons que vous avez apprécié cette newsletter et vous donnons rendez-vous en 2024 pour de nouvelles informations sur l’ALM. D’ici là nous vous souhaitons une très bonne fin d’année et prenez bien soin de vous !