Gérer facilement la conformité ISO 26262 tout en accélérant le cycle de développement
Continuer la lectureGestion de la conformité ISO 26262 aux exigences modernes
Maintenant publié : Modern Requirements4DevOps Mise à jour 1
Dans ce blogue, nous allons partager quelques points saillants apportés à certains de nos modules ainsi que quelques améliorations d’outils dans Modern Requirements, pour votre commodité.
Continuer la lectureRelever les défis courants de la gestion des exigences, via MR4DevOps
Dans cet article, nous allons vous montrer comment certaines entreprises éliminent tous les défis du développement de produits grâce à une solution simple de gestion des exigences : Modern Requirements4DevOps.
Continuer la lectureSmart Doc – Training Module
En tant qu’administrateur, vous pouvez contrôler la façon dont les utilisateurs accèdent et interagissent avec leurs projets Modern Requirements4DevOps en appliquant des paramètres administrateurs.
Continuer la lectureExportez vos résultats de test en utilisant Modern Requirements4DevOps
En tant qu’administrateur, vous pouvez contrôler la façon dont les utilisateurs accèdent et interagissent avec leurs projets Modern Requirements4DevOps en appliquant des paramètres administrateurs.
Continuer la lectureComprendre le panneau d’administration : Licences et configurations des modules
En tant qu’administrateur, vous pouvez contrôler la façon dont les utilisateurs accèdent et interagissent avec leurs projets Modern Requirements4DevOps en appliquant des paramètres administrateurs.
Continuer la lectureParticipez à la création d’exigences en utilisant Email Monitor
Participez à la création d’exigences en utilisant Email Monitor
La fonction Email Monitor permet d’accéder à la création d’éléments de travail dans votre projet Azure DevOps via un support qui n’est pas natif à Azure DevOps. C’est-à-dire que cela vous permet de communiquer avec votre projet par courriel. Les équipes se retrouvent souvent dans des situations où elles envoient des courriels concernant des exigences, des demandes de modification ou des bogues à créer, et elles peuvent souvent utiliser les courriels pour atteindre une exigence concluante qui devrait être ajoutée à leur projet.
Avec la fonction Surveillance des courriels, votre équipe peut maintenant transformer cette communication externe en un élément de travail directement.
Pour les cas d’utilisation et le processus de configuration d’Email Monitor, veuillez regarder la vidéo.
Vous pouvez accéder à la page de configuration de Email Monitor en allant dans les paramètres Collection/Admin – Modern Requirement4DevOps Extension – Services – Email Monitor.
En activant la fonction Surveillance des courriels dans le panneau d’extension Modern Requirements4DevOps, vous pouvez spécifier une adresse courriel Surveiller qui peut intercepter et créer tout élément de travail qui lui est envoyé par courriel. Puisque le système essaiera de capturer chaque courriel envoyé au courriel de surveillance, il est conseillé d’utiliser votre courriel de surveillance uniquement à des fins de moniteur de courriel.
Vous devez également fournir une adresse courriel d’administrateur au cas où le système ne reconnaîtrait pas les courriels, et un courriel de notification sera envoyé à l’adresse courriel d’administration.
Vous pouvez spécifier quels types d’éléments de travail vous souhaitez créer dans votre projet à partir de ces courriels capturés.
Les titres des courriels envoyés au courriel du Moniteur seront toujours mappés dans les titres des éléments de travail à créer.
Projet d’équipe (par défaut) vous permet de choisir un projet par défaut où vous souhaitez ajouter les éléments de travail.
La création d’ajouts et la mise à jour des ajouts vous aident à configurer quand vous voulez ajouter l’exigence au projet.
Pour le champ Description :
Si la création d’ajout est cochée, cela signifie que le système utilisera le courriel initial pour créer un nouvel élément de travail et que le corps du courriel deviendra la description de l’élément de travail créé.
Si la mise à jour Ajout est cochée, cela signifie que la description existante de l’élément de travail créé sera supplantée par de futures réponses concernant le même élément de travail.
Pour le domaine de l’histoire :
Si l’option Création d’ajout est cochée, cela signifie que le corps du courriel initial sera mappé à la section Discussion de l’élément créé.
Si la mise à jour de l’ajout est cochée, alors toutes les réponses aller-retour concernant le même élément de travail seront ajoutées à la section Discussion.
Le nom de l’expéditeur, le courriel de l’expéditeur et le corps du courriel vous permettent de définir le contenu que vous souhaitez ajouter dans la description associée ou dans la section Discussion.
Cas d’utilisation du service de surveillance de courriels
Le cas d’utilisation le plus courant de la fonction Email Monitor est le suivant :
J’ai une grande organisation et j’aimerais que tous les membres de mon organisation ajoutent tout bogue qu’ils trouvent dans mon logiciel à mon projet Azure DevOps.
Avec Email Monitor entièrement configuré avec le bugs@myorganization.com, toute partie prenante concernée peut simplement envoyer un courriel à bugs@myorganization.com et je pourrais spécifier qu’un élément de travail de bogue doit être créé dans mon projet.
En même temps, le courriel qui a déclenché la création du bogue est aussi envoyé aux personnes concernées de ce projet. Les membres concernés peuvent maintenant participer à la discussion de cet élément de travail par courriel, et toutes les communications par courriel seront ajoutées aux propriétés de discussion de cet élément de travail au sein de votre projet.
Cette fonctionnalité unique permet aux gens de contribuer au succès de votre projet sans avoir à accéder pleinement à votre projet Azure DevOps. Des parties externes peuvent maintenant participer à la discussion sur un Élément de Travail, et ne vous obligent plus à donner accès à votre projet.
D’autres scénarios pourraient t’intéresser
Ajout d’éléments de travail à des projets autres que le projet par défaut
Si l’expéditeur ne précise pas un nom de projet particulier dans le corps du courriel, le courriel mappé sera ajouté au projet par défaut. Si les expéditeurs souhaitent ajouter cette exigence à un autre projet de la même collection, ils devront inclure [NomProjet=GCD] dans le corps du courriel (GCD est un nom de projet exemple).
Types d’éléments multiples
Nous comprenons que vos parties prenantes de projet pourraient vouloir ajouter plusieurs types de postes de travail en utilisant Email Monitor. C’est aussi possible! Vous pouvez simplement sélectionner plusieurs types d’éléments de travail. Par exemple, maintenant je sélectionne Histoire utilisateur en plus de Bogue. Lorsque votre équipe envoie des courriels à la boîte courriel de surveillance, elle peut utiliser [WIT=bug] ou [WIT=user story] dans le corps du courriel pour spécifier quel type d’élément de travail doit être l’exigence créée. Sans préciser le type d’élément de travail dans le corps du courriel, le système tentera de correspondre le courriel au type d’élément de travail, qui relève de la catégorie d’élément de travail que vous avez sélectionnée dans la section Catégorie WI .
Ajout de contenu supplémentaire à un élément de travail existant
Après que le courriel initial ait été capturé par le système, par défaut, toutes les réponses futures peuvent être ajoutées sous forme de discussions sur le même élément de travail. En plus de cela, les expéditeurs peuvent ajouter [wiid=1997] (1997 est un exemple d’identifiant d’élément de travail) dans le corps du courriel pour ajouter du nouveau contenu à l’élément de travail ciblé existant.
Bien sûr, vous pouvez utiliser plus d’une de ces commandes spéciales dans un courriel selon vos besoins.
Gestion des besoins suspects avec un signalement automatique
Gestion des besoins suspects avec un signalement automatique
Lien Drapeau Sale / Suspect est une composante des services de gestion des ressources humaines (anciennement appelée Agent MR) utilisée pour identifier les éléments de travail susceptibles d’être affectés par le changement d’un élément lié afin que les parties prenantes concernées puissent examiner les éléments affectés. Par exemple, si une histoire utilisateur change dans les états actifs, alors les cas de test associés seraient marqués comme suspects.
La fonctionnalité Lien suspect contribue au succès de votre projet en rendant l’impact des modifications des éléments de travail à la fois interrogeables et, généralement, plus visible. Vous pouvez considérer cette fonctionnalité comme une méthode pour faire une évaluation d’impact sur l’évolution des éléments de travail au sein de votre projet.
Comment fonctionne le lien Dirty Flag / Suspect?
Cette fonction vous permet de surveiller les éléments de travail qui répondent à certaines préconditions. Lorsque ces éléments de travail changent, la fonction de surveillance marquera tous les éléments liés comme suspects.
Prenons un exemple :
L’histoire utilisateur 1 vient d’être déplacée en état « Terminé ». Si le lien suspect peut être configuré pour déclencher un drapeau si des modifications sont apportées aux histoires utilisateurs dans un état « Terminé » (c’est-à-dire un changement dans un champ tel que « Description »).
Cela signifie que si le champ Description de l’Histoire d’utilisateur 1 est modifié à l’avenir, il marquera toutes les exigences qui y sont liées avec un Drapeau Sale.
Cela permet à votre équipe d’identifier facilement si une exigence correspondant à un certain ensemble de critères (que vous spécifiez) change. Une fois identifiés, les éléments de travail configurés directement liés seront signalés par le Sale/Suspect.
Pour poursuivre notre exemple, si le champ Description de l’Histoire utilisateur 1 changeait, nous pourrions signaler un Dirty Flag de tous les cas de test directement liés qui pourraient devoir être modifiés pour tester les nouveaux critères.
Les drapeaux sales qui s’activent sur ces cas de test prendraient la forme d’une étiquette Objet de travail.
Les balises apparaissent dans l’éditeur Standard Work Item d’Azure DevOps. Vous pouvez aussi personnaliser les options de colonne dans le module Items de travail et backlogs pour voir un groupe d’items de travail dont certains peuvent être marqués par le drapeau Dirty.
Dans le cas de l’étiquette Dirty Flag qui est définie sur les éléments de travail, l’étiquette appliquée inclut à la fois l’ID de l’élément de travail modifié et la révision, afin que votre équipe puisse facilement identifier quelle exigence a modifié et déclenché la fonctionnalité Dirty Tag / Suspect Link.
Les balises Dirty Flag pourraient être retirées manuellement lorsque les parties prenantes concernées auront examiné l’impact et effectué les mises à jour nécessaires. Les meilleures pratiques que nous recommandons ici sont d’ajouter un autre commentaire expliquant que maintenant le Dirty Flag est retiré parce que les mises à jour nécessaires ont été effectuées ou qu’aucune mise à jour n’est requise.
Pour plus de détails et le processus de configuration du lien Dirty Flag/Suspect, veuillez regarder la vidéo.
Comment rendre vos identifiants de besoin plus descriptifs et distinctifs à l’aide d’un ID personnalisé
Améliorez la clarté et la distinctivité de vos ID d’exigence en utilisant Custom ID dans Modern Requirements4DevOps.
Continuer la lectureIntroduction à la gestion des droits
Introduction à la gestion des droits
Qu’est-ce que la gestion des droits?
La gestion des droits est une nouvelle fonctionnalité de la version MR2020 pour contrôler l’accès des utilisateurs. L’administrateur de projet peut accorder ou refuser à un groupe d’utilisateurs l’accès à un module MR et à ses fonctionnalités. Actuellement, la gestion des droits est disponible pour trois modules MR : Smart Docs, Baseline et Reporting.
Les avantages de l’utilisation de la gestion des droits
Des permissions flexibles et personnalisables permettent aux équipes de projet de maintenir l’équilibre approprié entre collaboration et contrôle.
Chaque fois qu’un changement de permission a lieu ici, il aura un impact immédiat sur chaque équipe ou groupe d’utilisateurs à qui les permissions sont attribuées. Cela garantit que les paramètres de permissions peuvent être facilement mis à jour et maintenus au fur et à mesure que les projets progressent et que les équipes changent de rôle.
Comment accéder à la gestion des droits
La gestion des droits est accessible depuis l’extension Modern Requirements4DevOps dans Paramètres du projet.
Caractéristiques du groupe
Les fonctionnalités disponibles pour lesquelles vous pouvez définir des permissions varient d’un module à l’autre.
Les caractéristiques de groupe disponibles sont les suivantes :
- Créer le dossier /Edit
- Supprimer le dossier
- Créer/mettre à jour un artefact
- Supprimer l’artefact
- Créer/mettre à jour un méta modèle
- Enregistrer comme modèle
- Génération intelligente de rapports
- Concepteur de rapports intelligents
Sélections des autorisations
Il y a généralement trois types d’accès aux permissions à choisir pour chaque fonctionnalité de groupe :
« Permets »
« Nier »
« Non Réglé »
- « Permettre » : Accorde explicitement aux utilisateurs la permission d’accéder à une fonctionnalité de groupe dans le ou les modules MR.
- « Nier » : Limite explicitement les utilisateurs d’accéder à une fonctionnalité de groupe dans le ou les modules MR.
- « Not Set » : Refuse implicitement aux utilisateurs la possibilité d’accéder à une fonctionnalité de groupe dans le ou les modules MR.
Permissions héritées
Teams/Groups peuvent automatiquement hériter des paramètres d’autorisation des Teams/Groups parent. Les paramètres des permissions modifiés explicitement dans les équipes/groupes enfants peuvent écraser les permissions héritées des équipes/groupes parents. Gardez en tête les règles suivantes :
- Les valeurs « Permettre » héritées peuvent être remplacées par « Refuser ».
- La valeur héritée « Non définie » peut être remplacée par « Permettre » ou « Refuser ».
- La valeur « Refuser » héritée ne peut pas être remplacée par « Permettre ».
Conflits de permissions
Lorsque le même utilisateur existe dans plus d’une équipe/groupe, les règles suivantes s’appliquent :
- « Nier » a la préférence sur « Permettre ».
- « Nier » a la préférence sur « Not Set ».
- « Permettre » a la préférence sur « Not Set ».
Veuillez regarder la vidéo tutorielle détaillée sur la gestion des droits!
Si vous avez des questions ou des idées concernant la gestion des droits, veuillez contacter votre représentant Customer Success de Modern Requirements et nous serons heureux de travailler avec vous pour explorer cette fonctionnalité.
