Développement d’un système d’administration de l’anesthésie en boucle fermée

En salle d’opération, les tâches de l’anesthésiste sont nombreuses. Alors que l’utilisation de nouveaux outils technologiques l’informe plus fidèlement sur ce qui se passe pour son patient, ces outils font que ses tâches deviennent plus exigeantes. En vue de diminuer cette charge de travail, nous avons considérer l’administration automatique d’agents anesthésiques en se servant de contrôle en boucle fermée. À cette fin, nous avons développé un système d’administration d’un agent anesthésique (le propofol) visant à maintenir à un niveau optimal la perte de conscience du patient pendant toute la durée d’une chirurgie. Le système comprend un ordinateur, un moniteur d’anesthésie et une pompe de perfusion. L’ordinateur est doté d’un algorithme de contrôle qui, à partir d’un indice (Bispectral IndexTM ou BIS) fournit par le moniteur d’anesthésie détermine le taux d’infusion de l’agent anesthésiant. Au départ, l’anesthésiste choisit une valeur cible pour la variable de contrôle BIS et l’algorithme, basé sur système expert, calcule les doses de perfusion de propofol de sorte que la valeur mesurée de BIS se rapproche le plus possible de la valeur cible établie. Comme interface-utilisateur pour un nouveau moniteur d’anesthésie, quatre sortes d’affichage ont été considérés: purement numérique, purement graphique, un mélange entre graphique et numérique et un affichage graphique intégré (soit bidimensionnel). À partir de 20 scenarios différents où des paramètres normaux et anormaux en anesthésie étaient présentés à des anesthésistes et des résidents, l’étude des temps de réaction, de l’exactitude des réponses et de la convivialité (évaluée par le NASA-TLX) a montré qu’un affichage qui combine des éléments graphiques et numériques était le meilleur choix comme interface du système. Une étude clinique a été réalisée pour comparer le comportement du système d’administration de propofol en boucle fermée comparativement à une anesthésie contrôlée de façon manuelle et conventionnelle où le BIS était aussi utilisé. Suite à l’approbation du comité d’éthique et le consentement de personnes ayant à subir des chirurgies générales et orthopédiques, 40 patients ont été distribués également et aléatoirement soit dans le Groupe contrôle, soit dans le Groupe boucle fermée. Après l’induction manuelle de propofol (1.5 mg/kg), le contrôle en boucle fermée a été déclenché pour maintenir l’anesthésie à une cible de BIS fixée à 45. Dans l’autre groupe, le propofol a été administré à l’aide d’une pompe de perfusion et l’anesthésiste avait aussi à garder manuellement l’indice BIS le plus proche possible de 45. En fonction du BIS mesuré, la performance du contrôle exercé a été définie comme excellente pendant les moments où la valeur du BIS mesurée se situait à ±10% de la valeur cible, bonne si comprise de ±10% à ±20%, faible si comprise de ±20% à ±30% ou inadéquate lorsque >±30%. Dans le Groupe boucle fermée, le système a montré un contrôle excellent durant 55% du temps total de l’intervention, un bon contrôle durant 29% du temps et faible que pendant 9% du temps. Le temps depuis l’arrêt de la perfusion jusqu’à l’extubation est de 9 ± 3.7 min. Dans le Groupe contrôle, un contrôle excellent, bon, et faible a été enregistré durant 33%, 33% et 15% du temps respectivement et les doses ont été changées manuellement par l’anesthésiste en moyenne 9.5±4 fois par h. L’extubation a été accomplie après 11.9 ± 3.3 min de l’arrêt de la perfusion. Dans le Groupe boucle fermée, un contrôle excellent a été obtenu plus longtemps au cours des interventions (P<0.0001) et un contrôle inadéquat moins longtemps (P=0.001) que dans le Groupe contrôle. Le système en boucle fermée d’administration de propofol permet donc de maintenir plus facilement l’anesthésie au voisinage d’une cible choisie que l’administration manuelle.

An empirical study of the impact of two antipatterns on program comprehension

Les antipatrons sont de “mauvaises” solutions à des problèmes récurrents de conception logicielle. Leur apparition est soit due à de mauvais choix lors de la phase de conception soit à des altérations et des changements continus durant l’implantation des programmes. Dans la littérature, il est généralement admis que les antipatrons rendent la compréhension des programmes plus difficile. Cependant, peu d’études empiriques ont été menées pour vérifier l’impact des antipatrons sur la compréhension. Dans le cadre de ce travail de maîtrise, nous avons conçu et mené trois expériences, avec 24 sujets chacune, dans le but de recueillir des données sur la performance des sujets lors de tâches de compréhension et d’évaluer l’impact de l’existence de deux antipatrons, Blob et Spaghetti Code, et de leurs combinaisons sur la compréhension des programmes. Nous avons mesuré les performances des sujets en terme : (1) du TLX (NASA task load index) pour l’éffort ; (2) du temps consacré à l’exécution des tâches ; et, (3) de leurs pourcentages de réponses correctes. Les données recueillies montrent que la présence d’un antipatron ne diminue pas sensiblement la performance des sujets alors que la combinaison de deux antipatrons les entrave de façon significative. Nous concluons que les développeurs peuvent faire face à un seul antipatron, alors que la combinaison de plusieurs antipatrons devrait être évitée, éventuellement par le biais de détection et de réusinage.

Impacts and Detection of Design Smells

Les changements sont faits de façon continue dans le code source des logiciels pour prendre en compte les besoins des clients et corriger les fautes. Les changements continus peuvent conduire aux défauts de code et de conception. Les défauts de conception sont des mauvaises solutions à des problèmes récurrents de conception ou d’implémentation, généralement dans le développement orienté objet. Au cours des activités de compréhension et de changement et en raison du temps d’accès au marché, du manque de compréhension, et de leur expérience, les développeurs ne peuvent pas toujours suivre les normes de conception et les techniques de codage comme les patrons de conception. Par conséquent, ils introduisent des défauts de conception dans leurs systèmes. Dans la littérature, plusieurs auteurs ont fait valoir que les défauts de conception rendent les systèmes orientés objet plus difficile à comprendre, plus sujets aux fautes, et plus difficiles à changer que les systèmes sans les défauts de conception. Pourtant, seulement quelques-uns de ces auteurs ont fait une étude empirique sur l’impact des défauts de conception sur la compréhension et aucun d’entre eux n’a étudié l’impact des défauts de conception sur l’effort des développeurs pour corriger les fautes. Dans cette thèse, nous proposons trois principales contributions. La première contribution est une étude empirique pour apporter des preuves de l’impact des défauts de conception sur la compréhension et le changement. Nous concevons et effectuons deux expériences avec 59 sujets, afin d’évaluer l’impact de la composition de deux occurrences de Blob ou deux occurrences de spaghetti code sur la performance des développeurs effectuant des tâches de compréhension et de changement. Nous mesurons la performance des développeurs en utilisant: (1) l’indice de charge de travail de la NASA pour leurs efforts, (2) le temps qu’ils ont passé dans l’accomplissement de leurs tâches, et (3) les pourcentages de bonnes réponses. Les résultats des deux expériences ont montré que deux occurrences de Blob ou de spaghetti code sont un obstacle significatif pour la performance des développeurs lors de tâches de compréhension et de changement. Les résultats obtenus justifient les recherches antérieures sur la spécification et la détection des défauts de conception. Les équipes de développement de logiciels doivent mettre en garde les développeurs contre le nombre élevé d’occurrences de défauts de conception et recommander des refactorisations à chaque étape du processus de développement pour supprimer ces défauts de conception quand c’est possible. Dans la deuxième contribution, nous étudions la relation entre les défauts de conception et les fautes. Nous étudions l’impact de la présence des défauts de conception sur l’effort nécessaire pour corriger les fautes. Nous mesurons l’effort pour corriger les fautes à l’aide de trois indicateurs: (1) la durée de la période de correction, (2) le nombre de champs et méthodes touchés par la correction des fautes et (3) l’entropie des corrections de fautes dans le code-source. Nous menons une étude empirique avec 12 défauts de conception détectés dans 54 versions de quatre systèmes: ArgoUML, Eclipse, Mylyn, et Rhino. Nos résultats ont montré que la durée de la période de correction est plus longue pour les fautes impliquant des classes avec des défauts de conception. En outre, la correction des fautes dans les classes avec des défauts de conception fait changer plus de fichiers, plus les champs et des méthodes. Nous avons également observé que, après la correction d’une faute, le nombre d’occurrences de défauts de conception dans les classes impliquées dans la correction de la faute diminue. Comprendre l’impact des défauts de conception sur l’effort des développeurs pour corriger les fautes est important afin d’aider les équipes de développement pour mieux évaluer et prévoir l’impact de leurs décisions de conception et donc canaliser leurs efforts pour améliorer la qualité de leurs systèmes. Les équipes de développement doivent contrôler et supprimer les défauts de conception de leurs systèmes car ils sont susceptibles d’augmenter les efforts de changement. La troisième contribution concerne la détection des défauts de conception. Pendant les activités de maintenance, il est important de disposer d’un outil capable de détecter les défauts de conception de façon incrémentale et itérative. Ce processus de détection incrémentale et itérative pourrait réduire les coûts, les efforts et les ressources en permettant aux praticiens d’identifier et de prendre en compte les occurrences de défauts de conception comme ils les trouvent lors de la compréhension et des changements. Les chercheurs ont proposé des approches pour détecter les occurrences de défauts de conception, mais ces approches ont actuellement quatre limites: (1) elles nécessitent une connaissance approfondie des défauts de conception, (2) elles ont une précision et un rappel limités, (3) elles ne sont pas itératives et incrémentales et (4) elles ne peuvent pas être appliquées sur des sous-ensembles de systèmes. Pour surmonter ces limitations, nous introduisons SMURF, une nouvelle approche pour détecter les défauts de conception, basé sur une technique d’apprentissage automatique — machines à vecteur de support — et prenant en compte les retours des praticiens. Grâce à une étude empirique portant sur trois systèmes et quatre défauts de conception, nous avons montré que la précision et le rappel de SMURF sont supérieurs à ceux de DETEX et BDTEX lors de la détection des occurrences de défauts de conception. Nous avons également montré que SMURF peut être appliqué à la fois dans les configurations intra-système et inter-système. Enfin, nous avons montré que la précision et le rappel de SMURF sont améliorés quand on prend en compte les retours des praticiens.