Déclaration : Pratiques de validation et d'assurance qualité des logiciels standard de ReliaSoft

ReliaSoft reçoit souvent des questions/demandes de clients/tiers concernant la validation des logiciels (généralement liées aux exigences de la FDA). Ce document a été créé pour répondre à de telles demandes.

Déclaration générale

Tous les produits sous emballage de ReliaSoft sont soigneusement testés et complètement validés avant leur commercialisation. Notre processus de validation strict, ainsi que notre documentation extensive sur l'utilisation du logiciel et les mathématiques sous-jacentes, garantissent (avec une très haute probabilité) que tous les résultats fournis par les applications ReliaSoft sont valides et corrects.

Les procédures de validation et d'assurance qualité (AQ) de ReliaSoft ont été développées indépendamment des exigences de validation de la Food and Drug Administration (FDA). Bien que nous croyions que les tests de validation de ReliaSoft sont d'une nature beaucoup plus large et beaucoup plus intensive que les exigences de la FDA, il incombe bien sûr à chaque organisation de déterminer si l'utilisation des logiciels de ReliaSoft sera conforme à toute directive réglementaire à laquelle elle pourrait être soumise. Nous nous attendons à ce que ce document fournisse la majorité des informations sur les procédures de ReliaSoft qui seront nécessaires pour que vous puissiez effectuer votre évaluation.

Validation indépendante de l'utilisateur final

Avec tous les produits standard sous emballage, ReliaSoft fournit une documentation extensive sous forme de guides de l'utilisateur, de fichiers d'aide et de manuels théoriques. L'objectif de la documentation est de présenter les méthodologies utilisées (équations et formulations), de fournir des exemples et de familiariser l'utilisateur final avec la théorie sous-jacente.

Un utilisateur final peut faire ce qui suit :

Confirmer de manière indépendante que l'application se comporte comme décrit dans ces guides.
Utilisez les manuels fournis pour effectuer une validation indépendante supplémentaire des résultats du logiciel, soit en utilisant les formulations données, soit en utilisant les nombreux exemples et solutions fournis dans ces manuels (dont beaucoup proviennent d'articles publiés).

De plus, des comparaisons entre les résultats numériques de ReliaSoft et les résultats publiés (par d'autres auteurs) sont également fournies avec la documentation imprimée.

Certains de ces manuels sont publiés sur le wiki public de ReliaSoft. Plus précisément, les références suivantes sont disponibles :

Les sections suivantes présentent un aperçu des exigences pour le développement de logiciels chez ReliaSoft.

Formulation théorique et développement de la théorie
Développement de code
Gestion du code source
Aperçu des procédures d'assurance qualité et de test
Tests unitaires
Tests d'intégration
Tests système
Tests d'installation et environnementaux
Tests de validation des résultats
Systèmes personnalisés
Tableau récapitulatif des tests logiciels (QA)
Processus de suivi et de résolution des problèmes
Déploiement de logiciels

Formulation théorique et développement de la théorie

Toutes les théories et formulations créées ou mises en œuvre par ReliaSoft doivent être théoriquement solides et correctes, acceptées par le milieu académique et les experts de l'industrie, et doivent également être soigneusement validées avant de devenir partie intégrante d'un produit logiciel standard (SSP).

Les théories et formulations qui ne sont pas créées par ReliaSoft doivent répondre aux normes suivantes :

Doivent avoir été publiées dans des revues académiques ou des manuels réputés et doivent avoir eu suffisamment de temps pour une évaluation par les pairs.
Doivent avoir été redérivées et validées par des scientifiques de ReliaSoft pour assurer la justesse du travail original.
Toutes les hypothèses formulées lors de la formulation doivent être examinées, bien documentées et comprises.
Doivent être examinées et approuvées par le comité de révision théorique de ReliaSoft et par au moins un autre expert académique indépendant sur le sujet.

Les théories et formulations développées par un scientifique de ReliaSoft doivent répondre aux normes suivantes :

Doivent documenter toutes les hypothèses formulées lors de la formulation.
Doivent être examinées et approuvées par le comité de révision théorique de ReliaSoft et par au moins deux autres experts académiques indépendants sur le sujet.
Si la publication de la formulation n'est pas considérée comme un avantage concurrentiel, elle doit être publiée dans des revues académiques réputées pour évaluation par les pairs. S'il existe un avantage concurrentiel, elle doit être publiée après la sortie du produit, soit dans des revues, soit dans des manuels ReliaSoft.

Développement de code

Tous les produits et composants de produits développés par ReliaSoft doivent respecter les normes acceptées dans l'industrie pour le développement d'applications orientées objet basées sur Windows, y compris les normes de l'industrie pour les interfaces graphiques utilisateur (GUI). De nombreux auteurs, y compris les publications de Microsoft et de Microsoft Press, proposent une large gamme d'articles et de livres détaillant les pratiques acceptées. De plus, ce développement de code doit respecter les directives pour le développement de logiciels selon le document interne de ReliaSoft "Pratiques et procédures de codage pour les logiciels SSP," et aux pratiques, méthodes et documents actuels publiés dans la section Développement de l'intranet de ReliaSoft.

Les directives de Microsoft pour le développement d'applications Windows (comme détaillé dans plusieurs documents, tels que "Spécification d'application pour Microsoft® Windows® 2000") sont respectées. Toute déviation, le cas échéant, par rapport à ces directives doit être approuvée par le comité de révision technique de ReliaSoft et les raisons de la déviation doivent être documentées.

Des revues de conception périodiques sont menées avec des membres de l'équipe de développement de code, des rédacteurs techniques et des responsables de l'assurance qualité. De plus, des comités de révision théorique et technique sont organisés.

Gestion du code source

Les directives mises en œuvre par ReliaSoft pour la gestion du code source sont les suivantes :

Tout le code source, y compris les modifications apportées au code, est suivi et contrôlé par l'utilisation de logiciels de contrôle de source tiers. En aucun cas, du code non suivi par le contrôle de source ne peut être introduit dans l'application.
Tous les builds de produits sont versionnés en utilisant un schéma de numérotation standard Major.Minor.Revision (par exemple, 3.1.2).
Tout le code compilé (composants) utilisé dans les applications ReliaSoft est contrôlé par les processus de configuration et de contrôle de version de ReliaSoft. Tous les composants sont capables (par le biais d'un événement ou d'une propriété) d'identifier leur version et leur build à une application hôte.

Aperçu des procédures d'assurance qualité et de test

ReliaSoft a toujours respecté les normes de qualité et de fiabilité les plus élevées pour tous ses produits et services logiciels. Les procédures d'assurance qualité (AQ) et de test pour tous les produits ReliaSoft, y compris les logiciels personnalisés, sont basées sur un cadre agile à échelle qui est facilité par CA Agile Central. Le processus agile à échelle implique des efforts de test détaillés et complets par plusieurs individus et équipes au fil du temps, des itérations spécifiques ; une documentation approfondie de tous les problèmes identifiés lors de chaque itération ; et une validation indépendante de toutes les méthodes, théories et résultats calculés.

Tests unitaires

Ces tests incluent des tests de bas niveau aux niveaux 'unité' et 'intégration'. Ils testent généralement des bibliothèques, etc. et sont donc effectués par des développeurs. Leur objectif est de s'assurer que le logiciel produit les résultats corrects (par exemple, 2+2 = 4). Ils doivent être complétés avant que les tests système puissent être conclus. Ce test unitaire garantit que les composants et les modèles fonctionnent comme prévu et assure également leur robustesse. Ce test est de la responsabilité des développeurs individuels et implique un processus de test-analyse-correction (TAAF).

Test d'intégration

Le test d'intégration implique que les testeurs recherchent des bogues dans les relations et les interfaces entre une paire de composants ou un groupe de composants. (Un exemple est la façon dont Weibull++ est intégré avec ALTA.) Le test d'intégration n'est pas nécessaire si l'application est composée d'utilitaires individuels qui ne partagent pas de données ou ne s'invoquent pas mutuellement. Cependant, si le logiciel utilise une API, partage des données ou passe le contrôle d'un composant à un autre, alors le test d'intégration devient une méthode importante pour vérifier que les composants fonctionnent ensemble correctement. Le test d'intégration nécessite que le testeur ait une bonne compréhension de la façon dont les composants sont censés fonctionner ensemble.

Test système

Une fois que tous les modules/composants ont été testés, compilés et liés sans erreurs ni avertissements, un test plus large est mis en œuvre sur l'application ou le système complet. Des journaux formels des activités de test système sont conservés dans notre système de suivi et d'enregistrement des bogues - CA Agile Central. En général, tous les problèmes trouvés sont corrigés au fur et à mesure de leur identification et les tests reprennent immédiatement avec la version corrigée pour s'assurer que la correction n'a pas créé de problèmes de régression. Une attention particulière est accordée au composant ou au problème qui a été corrigé. Cela se répète à chaque itération de la phase de développement.

Test d'installation et environnemental

La dernière phase de test est le test d'installation et de configuration. Ceci est effectué en interne sur plusieurs systèmes de test, y compris la plupart des versions de Windows® (par exemple, Windows 7 et 8.1, Windows 10). Lorsque cela est approprié, des retours d'expérience sont également obtenus de testeurs externes. Dans le cas de logiciels qui atteindront des marchés étrangers, des tests sur des systèmes d'exploitation étrangers (OS) sont également effectués (par exemple, Windows chinois, Windows coréen).

Test de validation des résultats

En parallèle avec les tests de fonctionnalité du logiciel, plusieurs ingénieurs, scientifiques et statisticiens travaillant indépendamment effectuent des tests et une validation de tous les résultats calculés. Les résultats validés sont soigneusement documentés et de nombreux exemples sont ensuite illustrés dans des manuels qui sont publiés avec le logiciel. Tous les problèmes trouvés sont corrigés, retestés et revalidés en utilisant plusieurs scénarios de données.

Décision de publication

Lorsque ReliaSoft publie un produit, il a été soigneusement testé et ReliaSoft a une grande confiance en sa qualité et sa fiabilité. Après que tous les problèmes ont été résolus et validés, une décision de publication est prise. Cette décision est basée sur le nombre et la fréquence des problèmes trouvés. Avant que la publication du logiciel puisse commencer, le Responsable de la publication doit s'assurer que toute la documentation de test a été approuvée (et que l'approbation pour la publication a été donnée) par le Responsable des tests.

Remarques finales

Dans le cas de systèmes personnalisés, nous nous attendons à ce que le client teste le produit pour s'assurer que le système fonctionne comme prévu dans l'environnement du client. Pour les systèmes qui intègrent une base de données non ReliaSoft pour soutenir la fonctionnalité et les calculs, le client est responsable de prendre des mesures pour maintenir l'intégrité des données stockées dans la base de données. Un aperçu des procédures de test employées par ReliaSoft est présenté dans le tableau suivant.

Tableau récapitulatif des tests logiciels (QA)

Phase de test	Type de test	Responsabilité	Détails des tests
Phase de développement	Tests unitaires Tests d'intégration	Développement QA Théorique	Effectuer des tests unitaires continus pendant le développement. Cela impliquera de tester des composants individuels au fur et à mesure de leur développement. À ce stade, les composants individuels seront testés pour la justesse des calculs ainsi que pour leur interaction avec d'autres composants.
Phase de test général	Test de processus Tests d'intégration Tests système	QA Développement Théorique Documentation	Valider les résultats du processus pour en vérifier l'exactitude. Suivre l'occurrence et la résolution de tous les problèmes anormaux. Tester la performance des composants lorsqu'ils sont entièrement intégrés.
Phase de test d'installation	Tests d'installation et environnementaux	QA Développement	Tester le système en interne/externe dans divers environnements d'installation. Pour les systèmes personnalisés, travailler avec le client pour tester le système sur le site de déploiement.
Phase de validation des calculs	Validation des calculs	Théorique	Valider un échantillon représentatif des calculs du système en effectuant des calculs identiques de manière indépendante et en comparant les résultats.
Phase de publication	Tests finaux	QA Développement Théorique Documentation	Tests d'unité, de processus, d'intégration, de fonctionnalité, d'utilisabilité et de déploiement.

Les tests à chaque phase sont cycliques, utilisant un processus de test-analyse-correction (TAAF). Tous les problèmes après la phase de développement initiale sont communiqués, documentés et résolus en utilisant CA Agile Central.

Processus de suivi et de résolution des problèmes

CA Agile Central suit tous les problèmes rencontrés pour chaque produit depuis la phase de développement et tout au long de son cycle de vie. Ce système intégré constitue la base de nos procédures d'assurance qualité. Tous les problèmes sont enregistrés dans CA Agile Central en tant qu'incidents et sont suivis de la création à la résolution. Chaque défaut est enregistré pour que l'équipe appropriée s'en occupe. Les défauts peuvent inclure des suggestions de clients, d'employés, des bogues trouvés lors des tests, etc. Une fois le défaut traité par le développement, il doit être testé par le groupe QA pour s'assurer que la solution employée traite correctement le problème et n'introduit pas de problèmes de régression supplémentaires. CA Agile Central facilite le travail d'équipe entre les développeurs, les experts théoriques, les rédacteurs techniques, le QA et la direction pour créer une application fiable et robuste.

La figure suivante montre l'une des interfaces de rapport de défauts dans CA Agile Central.

Interface de rapport de défauts dans CA Agile Central

Déploiement de logiciels

Une application logicielle n'est pas considérée comme prête pour le déploiement tant que le candidat à la version n'a pas été accepté par le groupe QA de ReliaSoft. Le groupe QA doit être satisfait de l'état actuel de l'application en fonction des résultats des tests.

Une fois qu'un produit est prêt pour le déploiement :

Un master est construit pour une duplication ultérieure.
Le système de contrôle de version est mis à jour pour inclure la configuration finale du produit et le code source pour la construction, puis est gelé.
Des sauvegardes du code source, des composants de construction et de la configuration de la machine utilisés pour la version de publication sont effectuées, et les versions des composants sont documentées (y compris les composants non ReliaSoft). Le stockage et l'emplacement des sauvegardes redondantes sont effectués conformément aux Protocoles de Récupération après Sinistre de ReliaSoft.
La machine utilisée pour la construction est ensuite isolée et gelée et ne peut être utilisée à d'autres fins que pour les constructions (révisions) ultérieures de la même version de l'application.

Main Menu

Main Menu

Main Menu

Main Menu

Find Your Sensor

Déclaration : Pratiques de validation et d'assurance qualité des logiciels standard de ReliaSoft

Déclaration générale

Validation indépendante de l'utilisateur final

Formulation théorique et développement de la théorie

Développement de code

Gestion du code source

Aperçu des procédures d'assurance qualité et de test

Tableau récapitulatif des tests logiciels (QA)

Processus de suivi et de résolution des problèmes

Déploiement de logiciels

Nous avons déménagé ${referer} vers www.hbkworld.com

Nous avons déménagé ${referer} vers www.hbkworld.com

Nous avons déménagé ${referer} vers www.hbkworld.com

Nous avons déménagé ${referer} vers www.hbkworld.com

Nous avons déménagé ${referer} vers www.hbkworld.com

Nous avons déménagé ${referer} vers www.hbkworld.com