Nous avons présenté la semaine dernière les grands axes du Capacity Management selon ITIL.

Si nous essayons d’appliquer ces bonnes pratiques au domaine de la qualité, quels sont les enseignements que l’on peut en tirer ? Que serait la gestion de la Qualité vue comme une analogie de la gestion de la Capacité ? Est-il possible de faire « plus avec moins » dans le domaine de la Qualité comme doivent le faire de plus en plus les équipes de Production ?

L’objectif premier du Capacity Management est de délivrer la capacité, c’est-à-dire les ressources dont vous avez besoin : un serveur de développement ou de test, un peu plus de disque dur pour une base de données, plus de puissance CPU dans une machine virtuelle, etc.

ITIL ajoute que la gestion de la capacité doit être assurée en accord avec les objectifs de niveau de service, dans les temps et de manière rentable.

Si l’on applique cette approche à la Qualité, on pourrait dire que le « Quality management » consiste à délivrer la qualité, dans le respect des accords de niveau de service ainsi que des délais et des budgets. Comment y parvenir ?

Connaître ce que l’on a

Afin de fournir la capacité, il faut connaître ce que l’on a. C’est la première étape et la base même d’un plan capacitaire. Vous ne pouvez pas gérer ce que vous ne savez pas que vous avez.

La virtualisation a eu pour conséquence de créer des silos technologiques et la ‘Prod’ doit être capable de mesurer le nombre de serveurs physiques ou virtuels, pour chaque OS, plate-forme de virtualisation, etc. Il en va de même pour les parcs applicatifs, qui ont vu s’accumuler au fil du temps différentes technologies : mainframe, client-serveur, progiciels, nouvelles technologies (J2EE majoritairement).

De plus, au cours de son histoire, une entreprise va évoluer sur différents marchés, créer de nouvelles activités, parfois acquérir d’autres sociétés, ce qui va multiplier les applications informatiques supportant ces différents business. La réorganisation du secteur bancaire en Espagne entraîne des fusions et des rachats de banques entre elles, et à chaque fois la question se pose : quelles applications utiliser et lesquelles jeter ? Cela peut paraître surprenant mais les départements TI de certaines de ces banques ne savent même pas combien ils ont d’applications et encore moins quelles technologies sont utilisées dans leurs applications ou les liens entre celles-ci.

Enfin, les hommes vont et viennent, changent de poste ou quittent l’entreprise, et la connaissance des applications se perd peu à peu au fil de ces mouvements. Un responsable Etudes dans l’administration me racontait une réunion au sommet entre les directeurs et des conseillers du ministère, afin de mettre en œuvre une décision récemment prise à Bruxelles et qui imposait un changement de réglementation douanière portant sur des centaines et des milliers de millions d’euros. Mais personne ne savait dire quels seraient les impacts de ces modifications sur le système applicatif qui gérait ces sommes. Il a fallu faire venir un vieux programmeur Cobol afin de lui demander s’il était possible de mettre en œuvre ces évolutions dans les délais impartis. Ce responsable me confiait qu’une telle réunion ne serait plus possible aujourd’hui, et comme je lui demandais pourquoi, il m’a répondu que ce programmeur Cobol était maintenant parti à la retraite et que la connaissance de ces applications s’était perdue avec lui.

Combien de fois un client qui souhaitait un audit applicatif ne savait pas combien de programmes, de fichiers contenait son application ? Et ne parlons pas de lignes de code.

La première étape d’un plan de Quality management reposera donc sur une analyse du parc applicatif. Un outil d’analyse de code permettra de disposer de données quantitatives concernant ce portefeuille, sur la taille des applications, le nombre d’objets, leur complexité, le niveau de documentation (commentaires) ou de code dupliqué, par exemple.

Connaître le niveau de qualité de ce que l’on a

L’analyse du portefeuille applicatif fournira également des mesures qualitatives concernant les risques encourus au niveau des différentes applications. Ces risques sont de deux natures :

• Risques pour l’utilisateur : bugs, erreurs, défauts empêchant ou gênant le fonctionnement de l’application, problèmes de performance générant des temps de réponse élevés, problèmes de sécurité ou de corruption des données, etc.
• Risques pour la maintenabilité de l’application : certains défauts de qualité ne vont pas entraîner un risque de défaillance pour l’utilisateur mais vont peser sur la maintenabilité de l’application, avec pour conséquences des retards de planning et des dépassements de budget.

Il est important de savoir quel est le niveau de non-qualité et la nature de celle-ci, pour chaque application, afin de savoir…

Répondre aux demandes des utilisateurs

« Plus avec moins » signifie répondre plus vite et mieux aux demandes des utilisateurs, sans augmenter le niveau de ressources dont on dispose afin de satisfaire ces demandes. La connaissance acquise grâce à un outil d’analyse de code permet de mieux estimer les efforts nécessaires pour implémenter les évolutions fonctionnelles requises par les évolutions de l’activité et du business.

Je vois souvent des utilisateurs se plaindre des retards pris par les équipes de projet pour délivrer une nouvelle version et du manque de fiabilité des prévisions de planning. Bien souvent ces équipes connaissent un turnover important, notamment lorsqu’elles sont outsourcées chez un provider qui tente d’ajuster au mieux ses effectifs au niveau d’activité des différents projets et fait passer les développeurs d’une équipe à l’autre en fonction des besoins.

Dés lors, comment chiffrer de manière fiable une modification dans un code que l’on ne connaît pas ?

Ce sera l’objet du post suivant.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.