Recette des activités d’ingénierie, de maintenance
Des choix sont à faire sur les processus de contrôles, de tests finals des résultats des activités d’ingénierie ou de maintenance, par le donneur d’ordres ou par d’autres acteurs à sa demande. Ces contrôles et tests sont à effectuer avant la mise en fabrication des produits, la diffusion des logiciels standard, la mise en exploitation et le déploiement des SI, l’utilisation des produits, logiciels, SI modifiés.
Les équipes de déploiement, d'exploitation, de maintenance/évolution, fabrication, vérifient que les logiciels, les SI sont déployables, maintenables, exploitables, évolutifs, que les produits sont prêts à être lancés en fabrication. Les donneurs d'ordres vérifient que les ensembles matériels et logiciels réalisent les fonctions spécifiées, sont déployables, utilisables.
L’objectif pour le donneur d’ordres est d’être raisonnablement convaincu de la qualité des livrables, en maîtrisant les délais et les charges de travail. La répartition des tâches de contrôle, de test, entre les acteurs est à effectuer de façon pragmatique, dans le respect des contrats, des responsabilités.
Des contrôles sont susceptibles d’être anticipés pendant la réalisation des travaux. Le donneur d’ordres, l’équipe d’exploitation… peuvent aider à la réalisation des tests du réalisateur technique.
Des comptes rendus de test peuvent être demandés au réalisateur technique.
Les tests fonctionnels du réalisateur technique sont fondés sur les spécifications. Il est en général efficace de les compléter par des tests fondés sur la vision des utilisateurs prévus.
Il peut être plus efficace, plus économique, que les tests de charge des SI soient faits par les équipes d’exploitation plutôt que par les équipes d’ingénierie.
Le donneur d’ordres peut demander que, pendant une période de VSR (vérification de service régulier), les contrôles du fonctionnement des SI soient renforcés.
Des non-conformités des ensembles matériels et logiciels, de leurs éléments associés, sont constatées pendant la recette, en fonctionnement, par le donneur d’ordres, les utilisateurs, les équipes d’assistance, d’exploitation, de déploiement, par des auditeurs... Elles sont signalées à leur équipe de maintenance. Les équipes d’ingénierie, de maintenance, ont également à traiter les non-conformités qu’elles ont identifiées elles-mêmes pendant leurs travaux.
Des anomalies sont parfois signalées par les constructeurs, les éditeurs des logiciels standard. Des choix sont à faire sur la stratégie de prise en compte des versions correctives proposées.
Le traitement des non-conformités par l’équipe chargée de l’ensemble matériel et logiciel concerné est susceptible d’inclure des tâches de qualification, d’analyse, de diagnostic, de correction.
Des procédures spécifiques sont à prévoir pour le traitement des anomalies critiques des SI, équipements, logiciels. Le donneur d’ordres souhaite en général être alerté et participer aux opérations.
1) La qualification peut nécessiter de disposer d’un environnement de test aussi proche que possible de celui des utilisateurs.
2) Les non-conformités qualifiées peuvent devoir faire l’objet d’un diagnostic, d’analyses, visant à déterminer leur cause (erreur de conception, de programmation, défaut de fabrication, usure, action malveillante...), les parties défaillantes de l’ensemble matériel et logiciel, l’étendue, la gravité des non-conformités.
Des informations, des ressources sont de nature à permettre ou à faciliter l’analyse, le diagnostic : messages d’anomalie émis, connaissance des ensembles matériels et logiciels, documentation, environnement de test, outils de diagnostic, historique des dysfonctionnements constatés, des opérations réalisées (traçabilité…), des versions des programmes, analyseurs de réseau.
Le diagnostic des anomalies importantes peut nécessiter des audits techniques des ensembles matériels et logiciels, l’utilisation d’outils d’analyse de code…
Il représente une part importante de la charge de travail du traitement des non-conformités. Tout ce qui permet de l’accélérer est de nature à augmenter la qualité du service, la productivité de l’ingénierie, de la maintenance.
3) Des analyses de la qualité ou de la complexité des logiciels sont réalisables, à partir d’outils d’analyse du code. En fonction de leur résultat, des choix sont à faire sur des actions éventuelles de réingénierie, de réécriture de programmes. On constate souvent que les défauts d’un logiciel sont concentrés dans un nombre limité de modules (error prone modules).
4) Sur la base des analyses, du diagnostic, des actions sont en général à lancer, à proposer : modification des programmes, dépannage ou remplacement du matériel, des liaisons, rétroingénierie, correction de la conception générale ou détaillée.… Elles sont à réaliser par les équipes internes d’ingénierie, de maintenance, ou par des fournisseurs externes.
Les actions de réingénierie sont par exemple le réusinage des logiciels, la mise à niveau des versions des logiciels, des tests renforcés, la refonte de la documentation…
Aucun commentaire:
Enregistrer un commentaire