Méthodologies de design et de développement de logiciels réglementés
Il en a résulté la nécessité de réglementer le développement de logiciels dans de nombreux domaines, tels que la médecine, l’énergie et la sécurité. Ces régulations ont tendance à être lentes à se faire et sont créées en réaction aux avancées technologiques. Contrairement à l’environnement réglementaire, les méthodologies de développement évoluent rapidement. Alors, comment pouvons-nous nous assurer que nous utilisons les meilleures méthodologies de développement logiciel, tout en créant un produit qui peut répondre aux exigences réglementaires ? Comment pouvons-nous imaginer une approche qui réponde avec efficacité aux lents changements de la réglementation et qui capitalise sur l’évolution rapide de la méthodologie de développement logiciel ?
L’interaction entre les développeurs de logiciels et les organismes de réglementation
L’objectif de la réglementation du développement logiciel est d’assurer la meilleure qualité possible du produit final tout en protégeant les utilisateurs. Pour ce faire, on établit des lignes directrices pour l’ensemble du processus de développement du produit — besoins, planification, conception, design, tests/vérifications et maintenance. Les règlements relatifs aux étapes de l’expression des besoins et du design aident l’organisme de réglementation à déterminer l’utilisation du produit et la meilleure façon de le tester. Ces étapes du développement entraînent la production de spécifications détaillées du produit. À partir de ces documents, les organismes de réglementation sont en mesure de déterminer les normes que le système doit respecter. Il en résulte généralement un processus de va-et-vient entre la partie chargée du développement et l’organisme de réglementation. Les étapes de tests et de vérifications comprennent des lignes directrices strictes. Cela permet aux organismes de réglementation de mieux s’assurer que votre système fonctionne comme décrit et qu’il répond aux exigences spécifiques. La dernière phase de la réglementation est la maintenance et la distribution du code — y compris la résolution de problèmes et la garantie d’une qualité constante. Bien que le code dans son ensemble ou les bibliothèques utilisées sont examinés, il y a beaucoup moins de lignes directrices associées à la façon dont le code devrait être écrit. C’est là que les développeurs doivent s’assurer que leur code est robuste, sécurisé et maintenable.
Définir et comparer deux méthodologies pour le développement de logiciels
Il y a deux méthodologies logicielles largement admises, en cascade et Agile, qui seront discutées dans ce billet de blogue. Chacune ayant ses propres avantages et inconvénients pour le développement de logiciels soumis à réglementation.
La cascade est une approche méthodique pour le développement de produits. Le modèle linéaire de cette méthodologie de développement logiciel permet une compréhension aisée des étapes. Dans la cascade, une fois que chaque tâche est achevée, l’étape suivante est amorcée. La première étape est la collecte des besoins, suivie du design, de la mise en œuvre, de la vérification et, enfin, de la maintenance. Pour des projets hautement définis et des besoins stables, la méthode en cascade est une excellente méthodologie de développement logiciel. Mais le format rigide de la méthodologie augmente le coût et allonge souvent le temps de développement — surtout dans les étapes ultérieures du cycle de développement du produit.
Comme d’autres méthodologies, celle-ci est assortie de certains compromis lorsqu’elle est utilisée pour élaborer des produits réglementés. La cascade répond aux exigences strictes en matière de documentation afin de s’assurer que le logiciel est conforme à la norme réglementaire. Dans une méthodologie en cascade pure, toute la documentation doit être créée et validée avant de passer à l’étape suivante. Bien que cette rigidité s’aligne sur celle de nombreux organismes de réglementation, elle n’a pas la souplesse nécessaire pour s’adapter rapidement aux changements. Posez-vous la question suivante : combien de fois un produit évolue-t-il entre le début et la fin de la production ? Cette approche linéaire du développement rend peu aisé l’ajout d’une caractéristique ou la modification de la portée d’un produit ou d’un projet. De nombreuses déviations par rapport à la direction originale coûtent du temps et de l’argent, car elles obligent les développeurs à revenir à l’étape des besoins ou à faire des correctifs et des « hacks » pour atteindre les résultats souhaités. Et cela s’ajoute à la dette technique que peut avoir un projet. Cette approche peut également conduire à du « code spaghetti » ; une situation où le “flux” d’un programme est embrouillé et sinueux. Les développeurs expérimentés savent qu’en ayant à faire de nombreux changements pour un projet soumis à un cadre réglementaire, les changements incrémentaux peuvent causer « code spaghetti », et si les inconvénients générés sont hors de la portée ce billet de blogue, on dira quand même qu’il faut vraiment l’éviter.
Agile se concentre sur le développement du logiciel par itérations qui sont de petits incréments de nouvelles fonctionnalités. Les avantages de ce type de développement sont qu’il segmente le code en différentes portions, créant ainsi une base de code plus nette. L’autre avantage des petits ajouts incrémentiels est que chaque caractéristique peut être testée indépendamment. Agile ne fonctionne généralement pas pour des équipes plus grandes ou celles habituées à la méthodologie en cascade. Elle est particulièrement utile pour les étapes ultérieures du développement ainsi que pour les projets axés sur l’interface utilisateur.
Contrairement à la cascade, Agile offre beaucoup de souplesse et permet d’échelonner le projet en sprints. Ce qui rend Agile unique est sa flexibilité, ce qui autorise une méthodologie plus adaptable et plus efficace, qui produit des tâches distinctes qui segmentent également le code. Le design est fait pour chaque fonction et chacune peut être étendue/modifiée à presque n’importe quel moment puisque cette méthodologie vous oblige à créer une séparation entre chaque fonctionnalité. Cela a le potentiel de réduire la dette technique d’un projet spécifique. En raison de l’itération rapide du développement Agile, une partie de la documentation peut être remise à la dernière phase. Examiner avant chaque sprint la documentation et s’assurer que chaque document est mis à jour peut consommer beaucoup de temps.
Développement de méthodes mixtes
La cascade soutient les équipes dans la mesure où elles n’ont pas à vérifier en permanence si leur produit répond aux besoins et aux normes, car elles sont en mesure d’évaluer la conformité de leur design dès le début du développement. Le contrepoids est la rigidité du processus qui le rend lent à s’adapter et à être modifié pour répondre aux demandes des clients, des marchés et aux changements technologiques.
De son côté, Agile donne aux équipes la flexibilité nécessaire pour effectuer des changements et des modifications en cours de route, mais exige que les équipes évaluent activement si chaque changement incrémental répond aux normes réglementaires.
Comment pouvons-nous répondre à l’exigence selon laquelle le développement doit être correctement documenté tout en utilisant une stratégie de développement souple et flexible ? Nous pouvons combiner les deux méthodologies pour minimiser les frais généraux et assurer les meilleures pratiques de codage.
Méthodologie hybride
La meilleure approche est de commencer par définir les objectifs commerciaux et les requis techniques à l’aide de la méthode en cascade. Une fois que les besoins et les objectifs sont définis de façon générale et qu’ils sont établis conformément à la réglementation, ils peuvent être découpés en composantes système de haut niveau. Une fois que nous avons un besoin de haut niveau et un design, nous pouvons utiliser la méthodologie Agile pour développer les fonctionnalités spécifiques au projet. À la fin du projet, nous revenons à la méthode en cascade pour vérifier l’ensemble du système.
Dans la phase de l’élaboration des besoins à haut niveau et du design, nous voulons déterminer l’objectif commercial que nous voulons atteindre et les éléments de haut niveau qui devront être conçus pour l’atteindre. Étant donné que les fonctions individuelles ne sont pas importantes pour les considérations réglementaires à ce stade, il n’est pas nécessaire de les définir parfaitement. L’organisation réglementaire peut vouloir s’assurer que vous utilisez les bons boulons, les bonnes bibliothèques et les bonnes pratiques de codage, mais ils ne se soucient pas vraiment de la façon dont vous écrivez une boucle, par exemple, ou les tenants et aboutissants de la façon dont le système se met à jour. C’est là que nous devrions utiliser le développement Agile, car il garantira la plus haute qualité de code. Et le résultat de l’étape précédente a dû nous générer un stock de tâches qui seront traitées à l’aide de la méthodologie Agile. Différentes caractéristiques peuvent être ajoutées ultérieurement, mais il est important de les garder dans le cadre du projet. Si vous concevez un avion autonome, vous ne pouvez pas facilement changer les fondations et réaliser un bateau autonome. C’est-à-dire que même la flexibilité de la méthode Agile doit être limitée pour assurer un développement réussi et opportun. Une fois le produit développé, nous pouvons revenir à un modèle plus linéaire pour compléter la phase de vérification.
En combinant deux méthodologies de développement, nous pouvons créer une approche pour développer des logiciels sur des marchés hautement réglementés tout en limitant les risques spécifiques. Ces risques sont le temps et/ou la dette technique. Cette méthodologie de développement combiné peut également être utilisée pour les domaines moins réglementés. Atténuer les risques, développer des systèmes robustes et assurer le développement futur sont des choses sur lesquelles toute équipe de développement devrait se concentrer. C’est particulièrement vrai lorsqu’on considère la direction de l’innovation technologique qui fait que tout est interconnecté. De bonnes pratiques nous permettront de nous sentir plus en sécurité et de développer des systèmes plus robustes.
L’importance de la méthodologie logicielle dans le monde d’aujourd’hui
Récemment, nous avons publié un autre billet de blogue qui souligne l’impact des données dans notre vie de tous les jours, et dans quelle mesure elles doivent être partagées avec les yeux omniscients de Google, Facebook et d’autres. Et comme il y est indiqué, « Une solide sécurité est la responsabilité de chaque développeur de logiciels et de produits, et devrait être prioritaire ». Cette affirmation est vraie pour de nombreux types de projets, et pas seulement pour les marchés réglementés.
