Découvrez comment la solution Parasoft Continuous Quality permet de contrôler et de gérer les environnements de test pour fournir des logiciels de haute qualité en toute confiance. Inscrivez-vous pour la démo >>
La conduite autonome est un espace très compétitif et la vitesse du développeur est un mantra. Celui qui peut le premier mettre un produit certifié sur le marché aura un avantage significatif sur la concurrence, et il est donc facile pour les développeurs de considérer l'analyse statique et d'autres initiatives de qualité comme un obstacle. Surtout parce que le domaine de la conduite autonome a soif de talents, les organisations recrutent des développeurs intelligents, même s'ils n'ont aucune expérience en matière de sécurité. Mais les développeurs qui viennent d'un milieu sans culture de sécurité fonctionnelle ne sont pas conscients de tous les processus de qualité requis pour le développement de logiciels critiques pour la sécurité. Cela peut faire de l'adhésion culturelle un défi.
Parfois, il semble que la construction d'un consensus interne pour des pratiques axées sur la qualité nécessite une maîtrise en psychologie, ou les compétences d'un négociateur qualifié ... Dans des projets antérieurs, j'ai été responsable de l'introduction de l'analyse statique et de la conformité aux normes de codage AUTOSAR C ++ 14 en tant que traiter. Le logiciel de conduite autonome est très innovant et les composants logiciels qui y sont utilisés sont développés en utilisant le C ++ moderne. Dans cet esprit, la norme de codage AUTOSAR C ++ 14 est la norme la plus appropriée pour les logiciels de conduite autonome, car elle prend en charge le C ++ moderne et a été créée pour un développement axé sur la sécurité.
Pour convaincre ceux qui ne sont pas convaincus, j'ai fait plusieurs présentations traitant de plusieurs aspects différents. Mais malgré toutes ces discussions et accords, certains développeurs résistent à analyser tout le code qu'ils créent. Voici quelques-uns des principaux points sur lesquels je me concentre pour mettre en place les bons processus:
La technologie de conduite autonome n'en est qu'à ses débuts. Une grande partie du code source créé n'est qu'un prototype pour tester de nouvelles idées. Certains développeurs ne veulent pas «perdre» de temps à le rendre conforme à la norme de codage - ils veulent juste écrire quelque chose rapidement et le tester. Une histoire typique que j'ai entendue est: "Je veux juste tester ce nouvel algorithme, s'il fonctionne, je réécrirai le code pour le rendre propre." Cela semble assez innocent, mais la réalité est qu'il ne s'agit que d'une dette technique croissante.
Lorsque nous passons d'un prototype à l'autre, nous emportons généralement beaucoup de code avec nous, statistiquement, cela peut représenter jusqu'à 80% du code. Nous ne pouvons donc pas nous permettre de prototyper quelque chose avec du mauvais code et de le réparer plus tard, car depuis le début, nous savons que nous n'aurons pas le temps pour cela. Donc, même si quelque chose est un prototype, le code doit être conforme car le produit final va contenir une quantité importante de code qui a été initialement créé sous forme de prototype.
Si au lieu de vous concentrer sur le faire maintenant au lieu de le faire plus tard, vous pouvez vous concentrer sur le faire maintenant pour éviter de passer un temps inconnu à la fin, les développeurs commencent à y voir une amélioration du processus au lieu d'introduire un ralentissement. Si vous pouvez intégrer efficacement le processus dans le flux de travail du développeur sans ralentir la vitesse ou la créativité, il devient beaucoup plus facile de travailler avec. Il est beaucoup plus facile de garder quelque chose en ordre et de nettoyer au fur et à mesure que de nettoyer un énorme gâchis, à la fin. Construire des pratiques cohérentes et maintenables pour écrire du code conforme vous aidera à trouver moins de gâchis plus tard.
Mais même si vous parvenez à introduire avec succès un processus de conformité aux normes de codage dès le début, il y aura inévitablement déjà une quantité (significative) de code qui a déjà été créée par l'équipe, et une autre qui a été héritée. Et pendant que vous sélectionnez l'outil d'analyse statique (test Parasoft C / C ++) et choisissez le standard (AUTOSAR), en attendant, l'équipe crée beaucoup de code sans aucune politique de conformité! Il est donc important de créer également une stratégie pour le code hérité. Deux grandes politiques sont:
Avec ces stratégies, vous pouvez traiter le code hérité, introduire un nouveau code et continuer à garder le lieu bien rangé.
Pour réussir à adopter des processus d'analyse statique et de conformité aux normes de codage dans l'ensemble de l'organisation de développement, vous bénéficierez des avantages suivants:
Ijaz est un ingénieur en sécurité fonctionnelle avec plus de 14 ans d'expérience dans le développement / test de logiciels. Son expérience récente s'est concentrée sur la technologie de conduite autonome, dirigeant l'effort de mise en œuvre de la norme ISO 26262 et la construction de scénarios simulés pour tester rigoureusement la technologie de conduite autonome.