Optimiser les opérations de maintenance de vos applications avec des outils d’analyse d’impact, de transformation et de test.
Dans de nombreux cas, une approche outillée des transformations d’un système d’information ou d’une application apporte de nombreux avantages et bénéfices par rapport à une approche manuelle traditionnelle.
Les cas d’usages
Si une approche outillée peut se généraliser avec profit pour la maintenance quotidienne elle trouve tout son intérêt dans les opérations de maintenance exceptionnelles qui nécessitent des transformations lourdes dans tout le système d’information.
On peut citer par exemple des projets :
- D’extension de zones. Augmenter la taille d’un identifiant, d’une zone
- De Changement d’utilitaire : Remplacer un gestionnaire de table de paramètre par un autre,
- De remplacement de fichiers Indexés par une base de données
- De changement de SGBD,
- De passage à une nouvelle version de compilateur,
- Etc…
Dans tous ces projets , il s’agit en pratique d’identifier, de manière exhaustive bien sûr, les points d’impacts, appliquer une ou plusieurs transformations sur ces impacts et s’assurer que l’on n’a pas introduit de régression.
Et la machine supplante l’homme
Dès que la volumétrie des éléments à modifier devient tant soit peu importante, la machine supplante l’homme dans tous les domaines.
Un être humain ou une équipe, si bonne soit-elle ne pourra pas analyser sans erreur des patrimoines de plusieurs millions de lignes de code et y appliquer de manière efficace les modifications.
D’une part, les coûts d’implémentation de ces modifications serait prohibitifs -même en offshore – et d’autre part, il n’est pas rare de devoir changer les spécifications en cours de projet. Avec une approche outillée, il suffit de modifier la règle de transformation et de régénérer. A la main, on recommence tout !
L’approche automatique permet également de prendre en charge facilement les reports de maintenance. Si le système évolue durant le projet, comme c’est le plus souvent le cas, on repasse la transformation et le tour est joué.
Trouver les bons impacts
L’analyse d’impact est LE sujet critique. Il est nécessaire d’identifier les lignes de code à modifier et seulement elles sinon des régressions interviendront.
Cette identification peut dans de rares cas être réalisée avec des outils rudimentaires, mais le plus souvent, notamment sur des patrimoines Mainframe, il sera nécessaire d’utiliser des algorithmes sophistiqués.
Prenez par exemple un patrimoine COBOL dans lequel vous souhaitez étendre la taille d’une zone qui est utilisée, agrégée avec d’autres pour constituer un identifiant composé.
Il vous faudra étendre non seulement la zone elle-même, mais toutes les zones groupes qui la contiennent ainsi que les variables intermédiaires, zones de communication entre programmes, tailles des fichiers, champs de base de données, en propageant l’extension dans toutes les instructions.
D’autres impacts secondaires doivent être identifiés comme les modifications à apporter dans les JCL sur la longueur des fichiers ou les décalages à mettre en œuvre dans des écrans ou des reports
Cela revient à faire une analyse approfondie du programme pour bien appréhender les structures de données et une sorte d’exécution en mode interprété pour identifier les impacts par propagation.
Faire cela à la main dans un patrimoine important relève de la gageure.
Et les tests ?
Sur les tests également, l’approche outillée permettra de sécuriser le projet sur tous les aspects. On pourra ainsi identifier tous les composants à tester en non régression. Ceux qui ont été modifiés évidemment, mais également ceux qui les utilisent.
Une approche de Tests de Non Régression stricts pourra être largement automatisée avec de plus une mesure du taux de couverture de ces tests.
Vite et bien !
Sur ce type de projets, la maintenance outillée permet de gagner sur tous les tableaux : Sécurité, Coûts, Planning.
On en parle ?
Image par Gerd Altmann de Pixabay
