Audit du code

Votre entreprise utilise Microsoft Dynamics NAV (NAV) ou Microsoft Dynamics 365 Business Central (BC) pour la comptabilité et la gestion de votre entreprise. Votre solution a été adapté à votre entreprise.

L'économie de la qualité

Microsoft a de centaine de milliers de clients utilisant NAV et BC, et les conséquences d'un bug sérieux sont énormes. De même, les meilleurs ISV ont des milliers de clients. Mais vos personnalisations ont été typiquement faites uniquement pour vous.

Vous pouvez avoir confiance que Microsoft met beaucoup de ressources dans le test de leur solution et que Microsoft a de grandes attentes envers ses partenaires ISV pour qu'ils fassent de même. Par exemple, en leur demandant de réaliser des tests automatisés couvrant la majorité de leur code.

La raison pour laquelle vos personnalisations n'ont pas ce niveau de qualité est simplement parce que vous

• ne l'avez pas demandé,
• ne le saviez pas,
• ne pensiez pas que c'était nécessaire,
• ne voyiez pas la valeur ajoutée,
• ne vouliez pas payer pour cela, ou
• pensiez que c'était inclus.

Directives de Programmation et Meilleures Pratiques

Depuis la toute première version de Navision Financials 1.0, Navision a fourni des directives de programmation à ses partenaires et aujourd'hui Microsoft continue de développer ces meilleures pratiques et modèles de conception.

Mais malheureusement, ces directives n'étaient souvent pas suivies par les développeurs. Pour différentes raisons.

Dette Technologique

Les personnalisations souffrent typiquement de ces conséquences. Nous appelons cela la dette technologique.

• Vous manquez les avantages de suivre les normes.
• Le code est difficile à comprendre, à maintenir et à mettre à jour.
• Il est difficile d'implémenter la qualité par la suite. Par exemple, en introduisant des tests automatisés par la suite.
• Le manque de robustesse conduit souvent à des erreurs d'exécution tôt ou tard.
• Différents styles de codage entre les programmeurs.
• Assez souvent, une mauvaise conception conduit également à une mauvaise expérience utilisateur.
• Dans certains cas, nous voyons également des problèmes de performance.

Pourquoi ai-je besoin de faire auditer ma solution ?

Si vous êtes DAF ou DT, vous devriez envisager d'investir dans un audit dans les cas suivants :

• Vous ne savez pas ce que vous avez hérité de votre prédécesseur.
• En général, si vous avez un doute sur la qualité de votre solution.
• Avant d'accepter la livraison de votre partenaire Microsoft.
• Tester que cela fonctionne n'est pas suffisant pour garantir la qualité de la livraison.
• Lors du changement de partenaire Microsoft.
• Avant de passer de NAV à BC.
• Avant de demander de nouvelles fonctionnalités à votre partenaire. Assurez-vous que la qualité est une condition pour accepter la livraison.

Si vous êtes un partenaire Microsoft

• Avant d'accepter un client venant d'un autre partenaire. Vous voulez connaître la qualité des personnalisations existantes.
• Lorsque vous travaillez avec des partenaires externes et souhaitez connaître la qualité de leurs livraisons.

Quel sera le résultat de l'audit

L'audit documente l'état actuel de votre solution. C'est un état des lieux. Nous essayons d'identifier les

• Risques potentiels d'erreurs d'exécution
• Problèmes de performance
• Lisibilité du code
• Robustesse
• Fonctions critiques où des tests automatisés pourraient être introduits

Dans le cas d'une mise à niveau de NAV à BC

• Ce qui devrait être changé ou réécrit
• Tester l'aptitude à la mise à niveau du code

Contact

Votre solution et votre historique vous sont propres. Parlons-en.

Finn Pedersen