Mettez en place une fondation solide pour éviter de rencontrer des difficultés en cours de route
Vous êtes tenté par les avantages des applications personnalisées mais vous hésitez à vous lancer ? Vous n’êtes pas seul.
Lorsqu’il s’agit d’automatisation et d’applications personnalisées, les opinions et les expériences vont de « La meilleure décision de ma vie ! » à « Plus jamais ! ».
D’une part, de nombreuses organisations ont compris les avantages d’adapter des applications standard à leurs besoins particuliers. Elles récoltent la valeur de la propriété intellectuelle de l’entreprise et l’intègrent dans leurs processus, acquérant ainsi un avantage leur permettant de se démarquer de la concurrence. Des données récentes montrent que 75 % des entreprises utilisent une forme ou une autre de code d’application personnalisé.
D’autre part, certaines entreprises refusent d’utiliser des applications personnalisées. « Plus jamais ! », s’exclament-elles. Ces entreprises ont par le passé essayé de mettre en œuvre une application personnalisée mais ont été extrêmement déçues par l’expérience. Puis, à un certain moment, elles aussi finissent par percevoir la valeur potentielle d’une application personnalisée. En fait, Maya HTT n’a encore jamais entendu quelqu’un dire que l’utilisation d’une application adaptée spécifiquement à ses besoins était une mauvaise idée, même si pour certains, c’est trop difficile ou trop coûteux d’essayer.
L’automatisation permet d’accélérer les processus en gagnant du temps. C’est évident. Qu’est-ce qui peut bien inciter certaines entreprises à rejeter cette solution ?
En règle générale, cela se résume aux raisons suivantes :
- Le coût initial de la programmation d’une application personnalisée est trop élevé.
- La maintenance d’un code personnalisé est coûteuse et ralentit les mises à jour.
- L’entreprise croit que seules les sociétés de développement de logiciels peuvent créer des applications personnalisées.
Explorons et abordons ces défis potentiels afin de nous assurer qu’ils ne l’emportent pas sur les avantages évidents des applications personnalisées.
Étape 1 : Effectuer une analyse du RCI
Avant de lancer un projet, il faut toujours effectuer une analyse du rendement du capital investi (RCI).
C’est une chose de prendre conscience d’un besoin précis et d’une solution potentielle mais il faut aussi comprendre le coût réel de la solution complète. Si l’analyse du RCI n’identifie pas des avantages évidents, il n’est pas judicieux de poursuivre le projet.
Conseil de pro : N’oubliez pas de tenir compte de votre propre temps dans l’équation. Si vous devez passer des mois à coder, vous devez en tenir compte dans l’analyse du RCI.
Étape 2 : Développer un PMV
Faites juste ce qu’il faut pour satisfaire vos besoins grâce à un produit minimal viable (PMV).
Il peut être tentant de poursuivre le développement une fois que le concept initial a été créé mais avant d’ajouter de nouveaux éléments, revenez à la première étape. Examinez à nouveau le RCI et mettez-le à jour au fur et à mesure que de nouvelles fonctionnalités sont identifiées et planifiées.
Étape 3 : Planifier la maintenance
Il est doublement important de planifier la maintenance du code.
De nos jours, si vous achetez une application standard, il est probable qu’elle soit soumise à un abonnement ou à un coût de maintenance annuel.
Les logiciels doivent s’adapter à l’environnement dans lequel ils fonctionnent, et celui-ci est en constante évolution. Que le système d’exploitation change, que d’autres applications soient mises à jour ou que des failles de sécurité soient découvertes, vous devrez apporter des modifications pour que vos applications restent synchronisées.
Par exemple, une mise à jour de logiciel ou un changement de système d’exploitation pourrait interrompre l’application et entraîner des retards pendant la recherche d’une solution. Comment pouvez-vous réduire ce risque ?
Étape 4 : Anticiper et prévenir
Les mises à jour et les changements de système d’exploitation font partie de la vie, il faut donc s’y préparer.
Veillez à ce que le service informatique soit informé de l’existence de tout code d’application personnalisé et procède à une analyse d’impact pour la planification des mises à jour futures. Si une application personnalisée est susceptible d’être affectée par des mises à jour logicielles, le fait de le savoir à l’avance donne à votre équipe le temps nécessaire pour apporter des modifications et faire les tests en fonction.
Étape 5 : Automatiser votre automatisation
La plupart des efforts déployés pour la maintenance d’une application sont consacrés aux tests et à la recherche d’erreurs. En réduisant ces tâches, vous pouvez économiser des efforts et des coûts considérables. La préparation de tests fiables pour le code de l’application à plusieurs niveaux vous permettra de gagner du temps et d’éviter des frais à l’avenir.
Tests d’intégration
À un niveau élevé, vous pouvez programmer des tests d’intégration, une version automatisée de ce que l’on peut également appeler des essais d’acceptation par l’utilisateur (EAU). Ce type de test intègre un ensemble d’informations, par exemple des fichiers ou des données de tableaux, en définissant tous les paramètres et options contrôlables par l’utilisateur, puis exécute l’application. Ensuite, vous devez vérifier le résultat par rapport à ce qui était attendu. Si vous disposez déjà d’un EAU, la planification de son automatisation est généralement l’étape la plus facile lors de l’ajout de tests rétrospectifs.
Le cadre de test que vous créez doit vous permettre de mettre en place un scénario avec les données d’entrée correctes, de stocker les options de l’utilisateur et d’agir sur celles-ci, puis de vérifier le résultat. En règle générale, la manière la plus simple de procéder à cette dernière étape de vérification des résultats consiste à comparer un résultat initial connu avec le dernier essai, en s’assurant qu’ils sont identiques ou suffisamment proches pour être considérés comme tels.
Une fois les tests d’intégration en place, si le système d’exploitation ou une autre application avec laquelle l’interface est établie est mis à jour, vous pouvez exécuter la suite de tests d’intégration pour savoir très rapidement si le changement a créé des problèmes. Signalons toutefois que les résultats des tests d’intégration sont « binaires » : ils vous indiqueront si un scénario s’est déroulé correctement ou s’il a échoué. Pour trouver la faille, il faut creuser davantage. C’est ici que le test unitaire entre en jeu.
Tests unitaires
Dans ce contexte, une unité représente la plus petite mesure de fonctionnalité de votre application, ou une fonction de base dans le code. La fonction, compte tenu d’un ensemble d’entrées connues, est censée produire certains résultats ou comportements.
Les tests unitaires sont très semblables aux tests d’intégration mais à un microniveau. Si vos tests sont bien structurés, il est fort possible qu’un test d’intégration échoue, et qu’un ou plusieurs tests unitaires échouent également. Vous comprendrez mieux pourquoi le scénario a posé problème, et vous pourrez alors vous concentrer sur cette partie du code pour la corriger.
Il est rarement facile d’ajouter rétroactivement des tests à un projet. Il est très utile que les développeurs structurent le code de manière à faciliter les tests.
Les tests devraient faire partie de tout projet dès le départ. Ils doivent donc être pris en compte dans l’analyse du RCI initial. Cela entraînera des coûts initiaux plus élevés mais vous économiserez du temps et de l’argent à long terme.
En effectuant une analyse du RCI, en planifiant la maintenance et en intégrant un cadre de tests automatisés, vous pouvez garder le contrôle de vos projets d’applications personnalisées.
En suivant ces étapes, vous aurez une vision précise des coûts et des avantages de votre projet, et vous serez sûr d’éviter les pièges qui en ont conduit certains à s’écrier « Plus jamais ! ».
Si vous avez besoin d’aide à un moment ou à un autre, communiquez avec un expert Maya HTT. Nous sommes là pour vous aider.