{"id":228,"date":"2012-10-15T11:18:55","date_gmt":"2012-10-15T10:18:55","guid":{"rendered":"http:\/\/dev.qualilogy.com\/fr\/?p=228"},"modified":"2013-01-05T11:19:25","modified_gmt":"2013-01-05T10:19:25","slug":"delivrer-la-qualite-12","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/delivrer-la-qualite-12\/","title":{"rendered":"D\u00e9livrer la qualit\u00e9 (1\/2)"},"content":{"rendered":"

\"\"<\/a>Nous avons pr\u00e9sent\u00e9 la semaine derni\u00e8re<\/a> les grands axes du Capacity Management selon ITIL.<\/p>\n

Si nous essayons d\u2019appliquer ces bonnes pratiques au domaine de la qualit\u00e9, quels sont les enseignements que l\u2019on peut en tirer ? Que serait la gestion de la Qualit\u00e9 vue comme une analogie de la gestion de la Capacit\u00e9 ? Est-il possible de faire \u00ab plus avec moins \u00bb dans le domaine de la Qualit\u00e9 comme doivent le faire de plus en plus les \u00e9quipes de Production ?<\/p>\n

L\u2019objectif premier du Capacity Management est de d\u00e9livrer la capacit\u00e9, c\u2019est-\u00e0-dire les ressources dont vous avez besoin : un serveur de d\u00e9veloppement ou de test, un peu plus de disque dur pour une base de donn\u00e9es, plus de puissance CPU dans une machine virtuelle, etc.<\/p>\n

ITIL ajoute que la gestion de la capacit\u00e9 doit \u00eatre assur\u00e9e en accord avec les objectifs de niveau de service, dans les temps et de mani\u00e8re rentable. <\/p>\n

Si l\u2019on applique cette approche \u00e0 la Qualit\u00e9, on pourrait dire que le \u00ab\u00a0Quality management\u00a0\u00bb consiste \u00e0 d\u00e9livrer la qualit\u00e9, dans le respect des accords de niveau de service ainsi que des d\u00e9lais et des budgets. Comment y parvenir ?<\/p>\n

Conna\u00eetre ce que l\u2019on a<\/strong><\/h3>\n

Afin de fournir la capacit\u00e9, il faut conna\u00eetre ce que l\u2019on a. C\u2019est la premi\u00e8re \u00e9tape et la base m\u00eame d\u2019un plan capacitaire. Vous ne pouvez pas g\u00e9rer ce que vous ne savez pas que vous avez.<\/p>\n

La virtualisation a eu pour cons\u00e9quence de cr\u00e9er des silos technologiques et la \u2018Prod\u2019 doit \u00eatre capable de mesurer le nombre de serveurs physiques ou virtuels, pour chaque OS, plate-forme de virtualisation, etc. Il en va de m\u00eame pour les parcs applicatifs, qui ont vu s\u2019accumuler au fil du temps diff\u00e9rentes technologies : mainframe, client-serveur, progiciels, nouvelles technologies (J2EE majoritairement).<\/p>\n

De plus, au cours de son histoire, une entreprise va \u00e9voluer sur diff\u00e9rents march\u00e9s, cr\u00e9er de nouvelles activit\u00e9s, parfois acqu\u00e9rir d\u2019autres soci\u00e9t\u00e9s, ce qui va multiplier les applications informatiques supportant ces diff\u00e9rents business. La r\u00e9organisation du secteur bancaire en Espagne entra\u00eene des fusions et des rachats de banques entre elles, et \u00e0 chaque fois la question se pose : quelles applications utiliser et lesquelles jeter ? Cela peut para\u00eetre surprenant mais les d\u00e9partements TI de certaines de ces banques ne savent m\u00eame pas combien ils ont d\u2019applications et encore moins quelles technologies sont utilis\u00e9es dans leurs applications ou les liens entre celles-ci.<\/p>\n

Enfin, les hommes vont et viennent, changent de poste ou quittent l\u2019entreprise, et la connaissance des applications se perd peu \u00e0 peu au fil de ces mouvements. Un responsable Etudes dans l\u2019administration me racontait une r\u00e9union au sommet entre les directeurs et des conseillers du minist\u00e8re, afin de mettre en \u0153uvre une d\u00e9cision r\u00e9cemment prise \u00e0 Bruxelles et qui imposait un changement de r\u00e9glementation douani\u00e8re portant sur des centaines et des milliers de millions d\u2019euros. Mais personne ne savait dire quels seraient les impacts de ces modifications sur le syst\u00e8me applicatif qui g\u00e9rait ces sommes. Il a fallu faire venir un vieux programmeur Cobol afin de lui demander s\u2019il \u00e9tait possible de mettre en \u0153uvre ces \u00e9volutions dans les d\u00e9lais impartis. Ce responsable me confiait qu\u2019une telle r\u00e9union ne serait plus possible aujourd\u2019hui, et comme je lui demandais pourquoi, il m\u2019a r\u00e9pondu que ce programmeur Cobol \u00e9tait maintenant parti \u00e0 la retraite et que la connaissance de ces applications s\u2019\u00e9tait perdue avec lui.<\/p>\n

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.<\/p>\n

La premi\u00e8re \u00e9tape d\u2019un plan de Quality management reposera donc sur une analyse du parc applicatif. Un outil d\u2019analyse de code permettra de disposer de donn\u00e9es quantitatives concernant ce portefeuille, sur la taille des applications, le nombre d\u2019objets, leur complexit\u00e9, le niveau de documentation (commentaires) ou de code dupliqu\u00e9, par exemple.<\/p>\n

Conna\u00eetre le niveau de qualit\u00e9 de ce que l\u2019on a<\/strong><\/h3>\n

L\u2019analyse du portefeuille applicatif fournira \u00e9galement des mesures qualitatives concernant les risques encourus au niveau des diff\u00e9rentes applications. Ces risques sont de deux natures :<\/p>\n

    \n
  • Risques pour l\u2019utilisateur : bugs, erreurs, d\u00e9fauts emp\u00eachant ou g\u00eanant le fonctionnement de l\u2019application, probl\u00e8mes de performance g\u00e9n\u00e9rant des temps de r\u00e9ponse \u00e9lev\u00e9s, probl\u00e8mes de s\u00e9curit\u00e9 ou de corruption des donn\u00e9es, etc.<\/li>\n
  • Risques pour la maintenabilit\u00e9 de l\u2019application : certains d\u00e9fauts de qualit\u00e9 ne vont pas entra\u00eener un risque de d\u00e9faillance pour l\u2019utilisateur mais vont peser sur la maintenabilit\u00e9 de l\u2019application, avec pour cons\u00e9quences des retards de planning et des d\u00e9passements de budget.<\/li>\n<\/ul>\n

    Il est important de savoir quel est le niveau de non-qualit\u00e9 et la nature de celle-ci, pour chaque application, afin de savoir\u2026<\/p>\n

    R\u00e9pondre aux demandes des utilisateurs<\/strong><\/h3>\n

    \u00ab Plus avec moins \u00bb signifie r\u00e9pondre 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\u00e2ce \u00e0 un outil d\u2019analyse de code permet de mieux estimer les efforts n\u00e9cessaires pour impl\u00e9menter les \u00e9volutions fonctionnelles requises par les \u00e9volutions de l\u2019activit\u00e9 et du business.<\/p>\n

    Je vois souvent des utilisateurs se plaindre des retards pris par les \u00e9quipes de projet pour d\u00e9livrer une nouvelle version et du manque de fiabilit\u00e9 des pr\u00e9visions de planning. Bien souvent ces \u00e9quipes connaissent un turnover important, notamment lorsqu\u2019elles sont outsourc\u00e9es chez un provider qui tente d\u2019ajuster au mieux ses effectifs au niveau d\u2019activit\u00e9 des diff\u00e9rents projets et fait passer les d\u00e9veloppeurs d\u2019une \u00e9quipe \u00e0 l\u2019autre en fonction des besoins.<\/p>\n

    D\u00e9s lors, comment chiffrer de mani\u00e8re fiable une modification dans un code que l\u2019on ne conna\u00eet pas ?<\/p>\n

    Ce sera l\u2019objet du post suivant.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Nous avons pr\u00e9sent\u00e9 la semaine derni\u00e8re les grands axes du Capacity Management selon ITIL. Si nous essayons d\u2019appliquer ces bonnes pratiques au domaine de la qualit\u00e9, quels sont les enseignements que l\u2019on peut en tirer ? Que serait la gestion de la Qualit\u00e9 vue comme une analogie de la gestion de la Capacit\u00e9 ? Est-il […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-228","post","type-post","status-publish","format-standard","hentry","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/228"}],"collection":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/comments?post=228"}],"version-history":[{"count":1,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/228\/revisions"}],"predecessor-version":[{"id":229,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/228\/revisions\/229"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=228"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=228"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=228"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}