Introduction
Si vous développez un dispositif médical qui utilise un logiciel, ou si vous développez un SaMD (Software as a Medical Device), il est important de comprendre et de respecter les exigences réglementaires applicables.
Les fabricants devraient s'intéresser à la norme IEC 62304 dès le début du processus de développement. Un problème courant est qu'il peut y avoir un décalage entre les développeurs brillants d’une part, la terminologie et les réglementations relatives aux dispositifs médicaux d’autre part. Cela peut se produire lorsqu'ils sont pris par la conception d'un nouveau logiciel génial, mais qu'ils ne s'intéressent pas aux exigences réglementaires à un stade précoce.
ADN vous propose un accompagnement dans l’implémentation des exigences de la norme CEI 62304 pour votre logiciel de dispositif médical ou SaMD.
Qu’est-ce-que l’IEC 62304 ?
La norme IEC 62304 : 2006 / AMD 1:2015 est la version actuelle de la norme internationale qui définit les processus du cycle de vie des logiciels utilisés dans les dispositifs médicaux. Cette norme est considérée comme une norme harmonisée et de ce fait est reconnue par les autorités réglementaires comme la Commission Européenne, la FDA et bien d’autres dans le monde.
Plus précisément, l’IEC 62304 s’applique à la fois au logiciel dispositif médical autonome (SaMD) et au logiciel intégré dans un dispositif médical final (SiMD).
Elle fournit des orientations pour la planification, le développement et les activités de surveillance après la mise sur le marché des logiciels de dispositifs médicaux. Elle doit être mise en œuvre dès le début de la phase de planification et doit se poursuivre après le lancement sur le marché.
Comment la CEI 62304 est-elle organisée ?
Le cadre de sécurité de l’IEC 62304 est censé être mis en œuvre en même temps qu'un système de gestion de la qualité (QMS) et un système de gestion des risques normalisé. Avec ces systèmes en place, l’IEC 62304 permet le développement et la mise en œuvre de logiciels en toute sécurité, au-delà des essais de produits et de l'analyse des risques.
Pour ce faire, elle définit trois classes de sécurité pour les logiciels. Chaque classe comporte des exigences différentes en ce qui concerne la documentation relative au processus de développement. La norme est divisée en 9 chapitres. Les 4 premiers chapitres définissent le champ d'application de la norme ainsi que les références, les termes et les exigences générales. Les 5 chapitres suivants sont clefs pour le respect de la norme IEC 62304 :
Chapitre 5 - Processus de développement des logiciels
Chapitre 6 - Maintenance des logiciels
Chapitre 7 - Gestion des risques liés aux logiciels
Chapitre 8 - Gestion de la configuration des logiciels. Elle comprend le contrôle des modifications et le suivi de l'état de la configuration
Chapitre 9 - Résolution des problèmes logiciels
Classification de la sécurité des logiciels selon IEC 62304 ?
Il est important de garantir la sécurité dès le début du développement. Les tests de produits ne suffisent pas à garantir la sécurité des patients. Or, la sécurité des patients est essentielle. De plus, intégrer la sécurité dans vos processus dès le début permet d'économiser du temps et de l'argent par la suite.
La classification de la sécurité des logiciels dans la norme détermine les processus liés à la sécurité que vous devrez utiliser. Cela a une incidence sur l'ensemble du cycle de développement des logiciels, depuis les exigences et le codage jusqu'à la publication et la maintenance.
La norme définit trois classes de sécurité pour les logiciels dans son Chapitre 2 – Exigences générales
Classe A : aucune blessure ou dommage pour la santé n'est possible
Classe B : une blessure est possible, mais sans gravité
Classe C : La mort ou des blessures graves sont possibles.
La documentation requise pour le développement du processus du logiciel dépend de la classification de sécurité, comme indiqué dans le tableau ci-dessous.
Documentation | Class A | Class B | Class C |
Development Planning | ✔ | ✔ | ✔ |
Requirements analysis | ✔ | ✔ | ✔ |
Architectural design | | ✔ | ✔ |
Detailed design | | | ✔ |
Unit Implementation | ✔ | ✔ | ✔ |
Unit verification | | ✔ | ✔ |
Integration & integration testing | | ✔ | ✔ |
System testing | ✔ | ✔ | ✔ |
Release | ✔ | ✔ | ✔ |
Maintenance | ✔ | ✔ | ✔ |
| | | |
Comment ADN vous accompagne ?
Pour se conformer à cette norme, les processus doivent être bien documentés. L'utilisation d'outils de gestion de cycle de vie logiciel tel que la suite Atlassian peut vous aider à répondre à ce besoin et à accélérer la mise en conformité.
Comment ? Prenons quelques exemples d’application pour chacun des 5 chapitres de la norme.
Chapitre 5 - Processus de développement des logiciels
Ce chapitre décrit les activités de développement logiciel à mener pour chaque classe de dispositif médical. L'utilisation d’Application de Gestion de Cycle de vie logiciel peut aider à répondre efficacement à ces exigences de documentation.
Exemples :
1. La gestion des exigences et spécifications logicielles
Deux choses des plus importantes à penser en matière de conformité à la l’IEC 62304, est la gestion des exigences, spécifications logicielles et l’assurance de leur traçabilité. La plupart du temps, nous remarquons que les exigences se trouvent documentées dans un fichier Word, une feuille calcul Excel ou pour les plus chanceux sur un wiki. Il en va de même pour les spécifications. La seule façon d'assurer la traçabilité verticale dans ce cas est de mettre des numéros à côté de chaque exigence et spécification, puis de copier et coller librement ces numéros dans les deux documents et de voir les informations devenir ingérables et impossibles à maintenir très rapidement. Pour simplifier ce travail fastidieux, l'intégration de Jira et Confluence est une excellente solution.
Avec ses propriétés de tickets JIRA et leur type, vous pouvez créer des types de tickets à allouer à chaque niveau de spécification logicielle à savoir SRS, SAD, SDD sous Confluence. Les bénéfices et avantages visibles pour le fabricant sont les suivants:
Chaque exigence logicielle pourra être identifiée grâce à son type, mais surtout sa clé automatiquement générée lors de la création du ticket.
De plus, Jira permet également d’établir des liens entre tickets. Le type de liaison permet par conséquent d'assurer la nature de la traçabilité entre exigences (couverture, dépendance, blocage, etc...). Ainsi, en explorant un ticket d'exigence on peut savoir duquel il découle et lesquels le couvrent.
Un audit trail JIRA est automatiquement enrichi à chaque modification d'exigence.
Les exigences sont également associées à une version logicielle.
La spécification est générée automatiquement et mise à jour sous Confluence en s'appuyant sur un filtre JIRA.
2. Mise en place des tests
L’IEC 62304 spécifie la nécessité d'établir des tests pour les exigences logicielles. Plusieurs solutions existent pour répondre à ce besoin : Nous vous proposons le plugin « X-Ray » de JIRA permettant de générer des cas de test liés aux exigences. Les bénéfices et avantages visibles pour l'entreprise sont les suivants:
Il crée un nouveau ticket de type « Test » auquel vous pouvez ajouter le bloc de texte standard ainsi que les différentes étapes de test que vous souhaitez. L'avantage de gérer vos tests sous JIRA est d'établir directement une traçabilité avec les exigences auxquelles ils sont liés.
X-Ray dispose également du type « Test plan » pour créer des cycles de test. L’exemple typique est celui d’une version logicielle à la fin d’un sprint. L’idée est de créer pour chaque sprint ou version logicielle, un ou plusieurs plans de test où seront logés l’ensemble des cas de tests du sprint. Ces plans de test ont pour avantage de suivre les résultats de test du sprint/version et de présenter à un instant donné une vue d’ensemble schématisée de l’exécution des tests à titre de preuve pendant la phase de vérification du design produit.
X-Ray permet de générer automatiquement une matrice de traçabilité entre les exigences, les tests, leur exécution et les bugs.
3. Processus de tests unitaires
Par ailleurs, les logiciels de classe B et de classe C doivent également établir un processus de vérification des unités logicielles. Vous pouvez satisfaire à cette exigence en utilisant les outils de couverture de code, d'analyse de code et de flux de données que propose votre plateforme de développement de logiciels (Gitlab, Bitbucket, etc...) dont l'intégration avec JIRA est possible pour harmoniser les données sur une même plateforme. Les bénéfices et avantages visibles sont les suivants:
Visualiser le code associé aux tâches de développement
Intégrer les activités de développement logiciel dans le planning global du projet
Automatiser l'avancement des tâches de développement par rapport au résultat des tests unitaires
Chapitre 6 - Maintenance des logiciels
Le chapitre 6 de l'IEC 62304 décrit le processus de maintenance des logiciels. Cela inclut:
L'établissement d'un plan de maintenance logiciel
L'analyse des problèmes et demandes de changements
L'implémentation des modifications
Au cours de cette phase, il est important de tenir compte des demandes de changements logiciels, du feedback des utilisateurs et de résoudre les problèmes survenus après la release du logiciel dispositif médical.
Pour des fabricants à budget contraint qui recherchent une solution de gestion de la maintenance logiciel à moindre coût et efficace, l'architecture basée sur une approche DevOps que nous proposons autour de la plateforme Atlassian est adaptée et permettra de mettre en place un processus de maintenance conforme aux exigences de ce chapitre de l'IEC 62304. Pour vous en convaincre, prenons quelques cas d'application.
Exemples :
L'établissement d'un plan de maintenance
De la même façon que Confluence sert dans le chapitre précédent à documenter les spécifications logicielles, il va également servir à documenter le plan de maintenance logicielle. Ce plan qui est amené à évoluer doit être versionné, approuvé et tracé comme tout document du SMQ. Nous nous appuyons sur notre outil DMC, plugin de Confluence, qui combiné à celui-ci constitue un système structuré de gestion de la qualité (SMQ) de façon électronique. Cette architecture personnalisée basée sur Confluence prend en charge des fonctions telles que la mise en œuvre, le versionnage, l'approbation avec signature électronique, l'accès sécurisé à la documentation et la conformité aux normes tout au long du cycle de vie du logiciel.
2. Analyse des problèmes logiciels
L'analyse des problèmes logiciels utilise le processus de résolution des problèmes logiciels pour documenter, évaluer les feedbacks utilisateurs qui aboutissent à un défaut logiciel. Ce processus fait la distinction entre les problèmes logiciels identifiés sur une release officielle et en cours de développement. La maintenance se focalise sur ceux identifiés sur une release.
En utilisant JIRA et Jira Service Management (JSM), il est possible créer un tel processus constitué des éléments suivants:
Inputs au processus: chaque problème est reporté sur un portail JSM configuré en fonction de la source du problème (utilisateur interne ou externe, non-conformité ou réclamation clients). L'interface du portail présente l'avantage d'être personnalisable avec plusieurs champs à renseigner pour chaque problème identifié.
Enregistrement: chaque problème enregistré via le formulaire JSM crée un ticket JIRA de type "Problem Report" qui reprend les champs précédemment renseignés parmi lesquelles l'actif (Asset) ou élément de configuration natif à JSM qui va permettre de cartographier les tickets. Chaque ticket créé de type "Problem Report" est accessible uniquement en interne à l'agent en charge de collecter et évaluer les problèmes après release. De cette façon, le problème est reporté et rangé automatiquement dans une base de données classée par listes en fonction du type d'actifs créés (logiciel, électronique, mécanique, ...) ou en fonction de l'actif en lui même (version logiciel par exemple). Chaque liste est constituée de plusieurs tickets de problèmes liés à un actif ou plus globalement au type d'actifs et pourra être revue périodiquement. Jira Software Management offre également la possibilité aux opérateurs chez le fabriquant d'interagir avec l'initiateur du ticket et ainsi de le tenir informé de l'état d'avancement du problème signalé. L'avantage ici est de centraliser toutes les informations sur une seule plateforme.
Evaluation: Chaque problème est évalué dans l'espace JIRA dédié pour déterminer s'il s'agit d'une anomalie, comment il affecte la sécurité du produit logiciel et quelle modification est nécessaire pour résoudre le problème. La portée du changement est évaluée et documentée grâce aux propriétés du ticket : versions logicielles concernées, spécifications logicielles liées, ressources et temps nécessaires pour résoudre le problème. Une fois l'évaluation faite, une priorité peut être assignée au ticket JIRA en fonction des résultats de l'évaluation.
3. Analyse des demandes de changements
Les inputs aux modifications logicielles peuvent provenir non seulement d'un besoin de résolution de problème, mais aussi de n'importe qui dans l'entreprise, de consultants externes, voir même des clients. Ces données doivent être communiquées au responsable du processus de maintenance, qui peut initialiser la demande de modification de la conception en créant un "formulaire de demande de changement de la conception" de la même manière que les reports de problèmes illustrés précédemment. Les demandes de modifications logicielles sont destinées à mettre en œuvre des changements spécifiques et limités, visant à apporter des améliorations au projet initial dans les domaines tels que la fiabilité, l'architecture, l'ajout de fonctionnalité, la facilité d'utilisation, la facilité d'entretien ou la facilité de fabrication.
La demande de changement créée sur le formulaire JSM est ensuite enregistrée et, si elle est approuvée, les modifications qui en résultent sont gérées comme des tickets de "changement logiciel" dans JIRA.
Le ticket de changement logiciel suit les étapes définies dans un workflow JIRA spécifique à ce type de tickets. De même, il peut être décliné en activités et artefacts (exigences, cas de tests, ...) qui peuvent être assignés et suivis individuellement.
4. Implémentation des modifications
Les changements logiciels nécessaires pour implémenter des modifications issues d'un problème logiciel ou d'une demande de changement doivent être mis en œuvre par l'équipe de conception de la solution logicielle: mise à jour de l'analyse de risques, des exigences logicielles sous JIRA, du codage et versioning. Une fois ces actions réalisées, une phase de test spécifique de vérification doit être menée. Pour vérifier que la mise en œuvre est correcte, des cas de tests sont créés et exécutés sous JIRA grâce au plugin X-Ray. L'exécution des tests est liée bien sûr au ticket source de la modification logicielle. Si le test est réussi, l'assigné change le ticket en RESOLVED. Dans le cas contraire, l'assigné doit continuer à travailler sur le problème jusqu'à ce qu'il obtienne le résultat escompté. Si l'équipe de conception du produit a décidé de ne pas poursuivre, le ticket passe en statut CANCELED.
Chapitre 7 - Gestion des risques liés aux logiciels
Le chapitre 7 de l'IEC 62304 décrit le processus de gestion des risques liés au logiciels.
Cela inclut:
l'identification et l'analyse des éléments logiciels contribuant aux situations dangereuses
la maîtrise des risques
la vérification de la maitrise des risques
Le processus de gestion des risques suppose l'existence d'une procédure de gestion des risques globale, conformément à la norme ISO 14971. Ainsi, la gestion des risques ne concerne pas seulement les logiciels. Elle peut également inclure la maitrise de risques pour des éléments tels que le Hardware ou les erreurs d'utilisation (URRA).
Ce processus est mis en œuvre et entretenu tout au long du cycle de développement du logiciel et vise à garantir que le logiciel est développé de manière à minimiser les risques pour la sécurité des patients.
Pour des fabricants développant un logiciel dispositif médical autonome (SaMD) ou un dispositif médical intégrant un logiciel (SiMD), la gestion des risques est une des pierres angulaires de leur conformité. Si vous utilisez déjà Jira pour d'autres activités de conception, des exigences des utilisateurs aux tests, il est logique de l'étendre également à la gestion des risques pour une visibilité et une accessibilité de bout en bout. Vous faciliterez également la participation et l'engagement des membres de votre équipe dans ce processus. Voyons quelques cas d'applications.
Exemples :
1. Analyse de risques des éléments logiciels
L'analyse des risques de manière globale peut être réalisée de différentes manières. De nombreuses techniques sont utilisées, notamment l'analyse préliminaire des dangers, l'AMDE et l'analyse des risques liés à l'utilisation. Le processus de gestion de risques doit pouvoir justifier le choix de l'une d'elle et définir les critères d'évaluation des risques. Le plug-In Softcomply Risk Manager propose pour chacune de ces techniques des modèles de tableaux des risques et des matrices d'évaluation à personnaliser en fonction de votre besoin.
Pour l'analyse des risques logicielles, le modèle de tableau d'analyse des dangers de SoftComply Risk Manager basé sur la norme ISO 14971 est approprié.
Ce tableau dispose déjà dans sa configuration native, des champs minimums sous forme de colonnes requis pour une approche d'analyse de risques de haut en bas. Ce tableau se présentant sous forme de feuille de calcul préremplie, constitue un excellent point de départ. Petite précision: pour un logiciel, la cause d'une situation dangereuse est son dysfonctionnement, encore appelée en gestion de risques "séquence d'événements". Ainsi pour plus de clarté, la colonne "Cause" peut être renommée par "Reasonably forseeable sequence or combination of events".
Les matrices d'évaluation des risques sont également personnalisables. On peut ainsi modifier les niveaux de gravité ou de probabilité et les classes des risques.
La matrice de risques configurée, on commencera à documenter des risques. Chaque risque enregistré, crée un ticket JIRA de type "Risk" qui reprend les valeurs des champs renseignés. L'évaluation d'un risque se fait en sélectionnant la probabilité d'occurrence du danger et le niveau de gravité conformément à la matrice d'évaluation. Automatiquement la classe du risque lui est attribuée après définition d'une gravité et probabilité.
2. La maitrise de risques
Pour chaque cas documenté dans le dossier de gestion de risques où un élément logiciel peut contribuer à une situation dangereuse, vous devez définir et documenter une mesure de contrôle du risque conformément à l'ISO 14971 pour des logiciels de classe B et C. La mesure de contrôle du risque peut être mise en œuvre au niveau matériel, logiciel, de l'environnement de travail ou des instructions destinées aux utilisateurs (IFU, Labelling). Dans le cadre de l'IEC 62304, nous nous intéressons aux mesures de contrôle mises en œuvre au niveau logiciel. Le tableau "Hazards analysis" de Softcomply propose déjà dans sa partie de droite des champs de base à la maîtrise de risques notamment la colonne des mitigations ou mesures de contrôle des risques, la probabilité et la gravité résiduelles.
Pour les mesures de contrôle des risques mises en œuvre comme partie des fonctions d'un élément logiciel, le fabriquant doit documenter la mesure de maîtrise des risques sous forme d'exigence logicielle (SRS, SAD, SDD) identifiée par un ticket JIRA existant ou à créer à partir du même tableau. Les propriétés affichées de ce ticket sont sa clé, son résumé et son statut. Ceci permet d'avoir un aperçu rapide des actions effectuées, en cours ou à faire. Pour répondre davantage aux exigences du standard CEI 62304, il faudra rajouter des colonnes "Software Item" et "Item Class" correspondant à l'élément logiciel où sera mise en œuvre la mesure de contrôle du risque.
Après avoir effectué votre analyse initiale du risque et défini les actions d'atténuation, il est temps d'évaluer les risques résiduels. Le même modèle propose des champs probabilité résiduelle et gravité résiduelle. En saisissant une valeur pour chacun de ces champs, la classe de risque résiduelle est automatiquement attribuée. Vous pouvez par conséquent, voir l'aperçu de l'évaluation ligne par ligne dans la première colonne "Risk" et un aperçu complet des risques initiaux et résiduels dans la vue matrice des risques.
3. Vérification de la maitrise des risques
Pour s'assurer que les mesures d'atténuation assignées au risque réduisent leur classe, vous devrez les vérifier. Tout comme les colonnes d'atténuation, les actions de vérification peuvent également être ajoutées en utilisant une colonne désignée "Verification links". Celle-ci permet d'ajouter des liens (liens de vérification) vers les cas de test d'un projet logiciel dans Jira. Vous pouvez également créer un nouveau cas de test à partir du tableau.
4. Production de la traçabilité des risques
Il existe plusieurs rapports sur les risques dans le gestionnaire de risques de SoftComply. Dépendamment de la plateforme et des outils que vous utilisez en plus de SoftComply Risk Manager, vous serez en mesure de produire différents type de rapports intégrés. En plus des rapports natifs "Plan de gestion des risques" et "Rapport de gestion des risques" préremplis et exportables sous différents formats, nous proposons des options supplémentaires de reporting des risks sur Confluence grâce au plugin SoftComply Risk Manager for Confluence Cloud. C'est une extension gratuite de Confluence pour les rapports de risques. Cette application vous permet de créer et de personnaliser des rapports sur les risques dans Confluence en ajoutant des matrices et des tableaux de risques sur vos pages Confluence.
Les bénéfices et avantages à utiliser l'écosystème Atlassian pour l'analyse de risques sont les suivants:
Proposition d'une interface collaborative qui permettra la participation et l'engagement des membres de votre équipe dans ce processus.
Une vue instantanée et toujours à jour de la matrice des risques sur Jira et Confluence: alors qu'Excel dispose de bonnes fonctionnalités pour divers diagrammes (y compris ces tableaux croisés dynamiques qui semblent se briser constamment), les applications SoftComply Risk Manager pour Jira disposent d'objets de matrice des risques à haute valeur ajoutée qui peuvent être ajoutés en quelques secondes à un tableau de bord de reporting Jira
Meilleure traçabilité de gestion de risques: liaison entre les risques, les mesures d'atténuation (exigences logicielles), de vérification des risques et éléments logicielles correspondant
L'assignation à un propriétaire de chaque risque identifié
Une analyse d'impact facilitée en cas de design changes
Aperçu de l'audit trail des changements : une gestion de risques dans Jira permet de voir l'historique complet des personnes qui ont créé, modifié et travaillé sur chaque élément de risque.
La possibilité d'exporter sous différents formats chaque document de la gestion des risques ou plus globalement le dossier entier (Risk Management File).
Chapitre 8 - Gestion de la configuration des logiciels.
Dans cette section de l'IEC 62304, vous devez décrire comment vous assurez la traçabilité des éléments de configuration du logiciel DM de manière à pouvoir récupérer une ancienne version et de la construire aisément. Ceci se résume en trois activités majeures:
L'identification des éléments constitutifs du logiciel, y compris la documentation
La maitrise des modifications et des versions des éléments logiciels
La fourniture de l'historique des modifications du logiciel
En utilisant les produits de la suite Altassian, on peut tout à faire construire un environnement de gestion des configurations du logiciel répondant aux exigences de l'IEC 62304. Voyons cela ensemble.
1. Identification des éléments de configuration du logiciel
On appelle élément de configuration tout artefact nécessaire à la création du livrable logiciel, y compris la documentation. Il en existe par conséquent de plusieurs types qui sont présentés sur l'image ci-dessous avec des exemples pour chacun.
Pour un système logiciel, les éléments de configuration constituant sa configuration doivent être documentés avec leur version pour une release du logiciel. Pour chaque SOUP utilisé incluant les bibliothèques standards, il faut documenter leur titre, le fabriquant et son appellation unique. Un fichier nommé "SOUPs List File" va permettre de recenser tous les SOUPs et leurs caractéristiques.
Le processus de maîtrise documentaire que nous proposons et qui s'articule autour de Confluence et DMC répond parfaitement à ce besoin de documentation à la fois de configuration du système logiciel, mais aussi de chaque élément de configuration de type documents.
2. La maitrise des modifications des éléments de configuration du logiciel
Toute modification d'un élément de configuration diffusé doit être initiée par l'approbation d'une demande de changement (change request) ou d'évolution. Un workflow de maîtrise des changements doit être décrit dans le processus de contrôle des changements. La figure qui suit est un exemple de workflow classique de gestion des demandes de modifications ou d'évolutions sous Jira qui va nous permettre de gérer les CRs sous forme de tickets.
A l'issue de l'analyse d'impact d'une demande de changement/d'évolution, les éléments impactés vont être identifiés parmi lesquels des éléments de configuration le cas échéant qui vont être assignés pour implémentation. Après implémentation, la modification va être vérifiée et la traçabilité entre CR et PR se fait naturellement grâce au lien Jira entre les deux.
3. La fourniture de l'historique de modification du logiciel
Il s'agit ici de conserver les enregistrements récupérables de chaque version des éléments de configuration y compris la configuration du système logiciel.
Pour ce faire, à chaque fois qu'un élément de configuration est modifié, son état précédent est conservé. Ceci est tout fait possible sous Jira et Confluence où des versions antérieures diffusées ou non des enregistrements du SMQ (documents) sont récupérables plusieurs itérations après sur la GED construite autour de Confluence.
Pour des éléments de configurations du type programme, leurs états successifs sont naturellement sauvegardés sous Git grâce aux commits et tags associés aux releases.
Le fait de pouvoir mutualiser la gestion des configurations du logiciel aux autres processus dans un même outil ALM ne peut être que bénéfique:
Identification rapide des éléments de configuration impactés par une modifications grâce à leur format (page Confluence, ou élément d'architecture sous forme de ticket Jira)
Récupération aisée des enregistrements de chaque version d'élément de configuration grâce aux propriétés de versioning de Confluence, DMC et Git sous Bitbucket
Etablissement de points de références entre une release logiciel et ses éléments de configuration logiciel
Contrôles d'accès garantis pour préserver l'intégrité des éléments de configuration. Ainsi, seul le personnel autorisé doit avoir la possibilité d'apporter des modifications aux éléments de configuration
Rationalisation du processus de développement et réduction des conflits: Atlassian élimine le syndrome du "ça marche pourtant sur ma machine"
Chapitre 9 - Résolution des problèmes logiciels
Date prévisible de publication: 31 Mai 2024
Conclusion
La norme IEC 62304 est l'un des piliers de notre système intégré de gestion de la qualité.
Notre équipe de consultants ingénieurs très expérimentée dans le développement de dispositifs médicaux SaMD et SiMD peut vous accompagner dans la mise en conformité à la norme CEI 62304 dans un environnement agile.
N'hésitez pas à nous contacter via le formulaire ci-dessous afin que nous puissions discuter de votre projet et des options qui s'offrent à vous.