Your SlideShare is downloading. ×
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Qualité du code - le revers de la médaille
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Qualité du code - le revers de la médaille

694

Published on

L’externalisation des activités de maintenance applicative séduit une large majorité de directions informatiques, en leur permettant de recentrer les investissements au profit d'autres projets. Mais …

L’externalisation des activités de maintenance applicative séduit une large majorité de directions informatiques, en leur permettant de recentrer les investissements au profit d'autres projets. Mais quels sont les engagements pris sur la qualité du livrable lui-même, à savoir le code ? Quels sont les risques financiers de ne pas contrôler le niveau de maintenabilité, d’évolutivité ou de conformité d’une application ? Les réponses à ces questions sont examinées dans ce livre blanc qui analyse les risque d'absnece de contrôle et fait le point sur les bonnes pratiques.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
694
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. metrixware Livre Blanc TMA Qualité du code : Le revers de la médaille ? Juin 2009© Copyright Metrixware, 2009. Tous droits réservés. Livre blanc 1
  • 2. metrixware Livre Blanc L ’externalisation des activités de maintenance applicative a déjà séduit une large majorité de directions informatiques, en leur permettant de recentrer investissements et ressources au profit des nouveaux projets, source de valeur pour l’entreprise. Flexibilité, réactivité et maîtrise des coûts sont autant d’arguments avancés par les acteurs d’un marché de plus en plus compétitif. Mais quels sont les engagements pris sur la qualité du livrable lui-même, à savoir le code ? Quels sont les risques techniques de ne pas contrôler – et suivre dans le temps – le niveau de maintenabilité et d’évolutivité d’une application ? Quel serait l’impact financier de 4 millions de lignes de code rendues non conformes à la nouvelle architecture SOA de votre système d’information ? Des questions essentielles pourtant trop souvent, encore aujourdhui, laissées en suspens, et finalement sans réponse. Spécialiste de la qualimétrie et de la gouvernance des systèmes dinformation depuis sa création en 1995, Metrixware décrypte dans le présent livre blanc le marché de la TMA et son évolution, analyse les risques de labsence de contrôle qualimétrique des applications et fait le point sur les bonnes pratiques à engager entre les entreprises et leurs prestataires de tierce maintenance applicative. Remerciements Metrixware tient à remercier tout particulièrement Messieurs Rémy BERTHOU (Directeur du Système d’Information Voyageurs de la SNCF) et Georges MONTOYA (Directeur Outsourcing de Logica) pour leur disponibilité et aimable participation à ce livre blanc. 2© Copyright Metrixware, 2009. Tous droits réservés.
  • 3. metrixware Livre Blanc La TMA : une solution adaptée aux besoins des DSI ................................................. 4 Encore très jeune, le marché de la TMA connaît une croissance spectaculaire de près de 10% par an. Pourquoi un tel engouement des DSI pour la TMA ? A quels enjeux des entreprises la TMA répond-elle ? Les risques liés à la qualité du code ......................................................... 14 Évolution rapide des métiers, apparition de nouvelles technologies... Le système dinformation se doit aujourdhui dêtre très agile. En quoi la qualité du code, à lorigine comme en cours de maintenance, peut-elle influer sur lutilité fonctionnelle, les coûts de possession et la durée de vie des applications ? Les bonnes pratiques du contrôle qualité des Tierces Maintenances Applicatives ................................................... 20 La mise en place d’un contrôle régulier à chaque phase majeure du projet améliore la gestion du risque qualité et pérennise l’application sous-traitée. Quels outils mettre en œuvre ? A quelle phase du projet ? Quels enjeux dans la relation client / fournisseur ? Les entretiens – 3 questions à… Georges MONTOYA, Directeur Outsourcing de Logica…......................................11 Rémy BERTHOU, DSI de SNCF Voyageurs………………….....…………………...23 3© Copyright Metrixware, 2009. Tous droits réservés.
  • 4. metrixware Livre Blanc La TMA : une solution adaptée aux besoins des DSI Apparue au début des années 1980, la Tierce Maintenance Applicative est aujourd’hui un des moteurs du marché français des services informatiques. Avec une croissance annuelle soutenue, supérieure à 10% depuis ces dernières années et qui devrait se maintenir à près de 8% dans les prochaines années selon IDC, ce marché porteur, animé par de grands acteurs de l’intégration comme de petites SSII spécialisées, attire désormais aussi bien les grands comptes que les PME-PMI. Tous voient dans la TMA une solution pour gagner en productivité, prévoir et moduler les coûts de personnel, en s’assurant contractuellement de la qualité et de la performance du service offert. Un marché porté par la gouvernance IT La gouvernance IT consiste à aligner l’ensemble de l’informatique d’entreprise (investissements, moyens humains, actifs technologiques, organisation) sur la stratégie et les objectifs de croissance, de rentabilité, de compétitivité ou encore dagilité, fixés par la Direction Générale. A ce titre, la Direction Informatique – souvent perçue par l’entreprise comme un poste coûteux (3 à 10% du CA selon les secteurs d’activités) – se doit doptimiser sa valeur ajoutée dans lentreprise, tout en stabilisant, voire en réduisant, les coûts qui lui sont associés. Pour cela, elle dispose de trois principaux leviers : technique, organisationnel et économique. Investir au profit de la création de valeur « Cest au système dinformation de sadapter aux besoins des directions métiers et non linverse ». Trop longtemps ignorée, volontairement ou non, cette affirmation prend, depuis quelques années, tout son sens. Les DSI ont aujourdhui pris conscience de la nécessité de concentrer leurs investissements vers la modernisation de leurs actifs 4© Copyright Metrixware, 2009. Tous droits réservés.
  • 5. metrixware Livre Blanc informatiques afin de garantir un système dinformation performant, réactif et tourné vers les demandes métiers. Dans certains secteurs, nombreuses sont les évolutions voire les révolutions de lenvironnement, quelles soient structurelles ou conjoncturelles, qui ont mis ce besoin en lumière. Cest le cas notamment du secteur des mutuelles et assurances avec une modification sensible de la relation client depuis plusieurs années, de la banque de détail dont la plupart des services est désormais accessible sur Internet ou bien encore du secteur financier qui a subi une profonde concentration au fil de fusions/acquisitions successives. Sur le plan technologique, ces mouvements ne sont pas sans conséquence. Outil aujourdhui indispensable aux activités métiers, le système dinformation doit savoir évoluer et sadapter, le plus rapidement et le plus économiquement possible, aux nouveaux impératifs du marché. Une impulsion qui se traduit par de simples évolutions ou par dimportants chantiers de migrations dapplications, (Procédural vers Objet, Cobol vers Java pour plus de modularité), de migrations de données vers un ERP ou encore de mise en place d’une architecture SOA, etc. Dans tous les cas, il sagit de fonder des systèmes dinformation agiles et fluides dans leur capacité dadaptation aux mouvements, de plus en plus rapides et fréquents, des métiers. Fiabiliser et pérenniser l’activité informatique Après plusieurs décennies deuphorie, les activités informatiques murissent et gagnent en stabilité. Fini le temps des budgets illimités, des projets qui naboutissent jamais et des applications « short term », lheure est aujourdhui à la raison et à la réflexion à long terme. Pourtant, la prise de conscience est encore toute récente : selon une étude du cabinet Loudhouse réalisée en 2007, un projet informatique sur trois dépasserait son budget de 10 à 20%, tandis quun sur quatre laugmenterait allègrement de 50%, à moins dêtre purement et simplement abandonné. La même étude révèle dailleurs que 39% des responsables informatiques ne possèderaient pas une vue densemble suffisante de leurs projets et moins de la moitié (42%) ne sont pas tenus informés dans la journée des éventuels problèmes rencontrés sur les projets. Cest la raison pour laquelle de nombreuses DSI mettent en place et appliquent désormais, à l’aide de cellules Qualité & Méthodes transverses, des référentiels de bonnes pratiques et des processus. Lobjectif étant simple : assurer une amélioration continue de l’activité 5© Copyright Metrixware, 2009. Tous droits réservés.
  • 6. metrixware Livre Blanc informatique afin dendiguer les gouffres financiers et limiter la déperdition d’énergie des équipes informatiques, quelles soient internes ou externes. L’industrialisation des développements (centres de services internes), les référentiels CobIT ou ITIL, l’application du modèle CMMi ou bien encore la généralisation des indicateurs clés de performance sont autant dexemples de bonnes pratiques qui permettent d’assurer la bonne conduite, le succès et surtout la pérennité des projets informatiques. Rationaliser et maîtriser les coûts opérationnels Au-delà dun simple respect des budgets, les directions informatiques doivent désormais composer, au même titre que les autres directions opérationnelles, avec des budgets plus serrés, et parfois même réduits dune année sur lautre. A ce titre, lefficience, soit en dautres termes la recherche du meilleur rapport entre la pertinence du service rendu et le coût qui lui est lié, nest plus un vain mot. La bonne gouvernance du système dinformation en général, et de l’informatique en particulier, entend ainsi une meilleure visibilité sur les dépenses liées à son fonctionnement. Cest ainsi que le recours à la sous-traitance de toute ou partie de l’activité de maintenance du système d’information est apparu et sest accéléré ces dernière années. La raison en est simple : chez un sous-traitant, lactivité de maintenance, dont cest le cœur de métier, est totalement industrialisée et engendre dimportantes économies déchelle, bénéficiant forcément au client. Sans compter une souplesse de fonctionnement appréciable en cas de variations de lactivité. Une mise en perspective très adaptée à la maintenance applicative, qui représente 50 à 80% du budget Études selon les secteurs. Pour expliquer un tel état de fait, il suffit dapprécier le caractère de plus en plus complexe et fortement hétérogène du parc applicatif des entreprises. Au fil des années et des évolutions, les applications ne sont plus aussi modulaires qu’à leur conception. Les corrections effectuées ne sont bien souvent pas documentées, ou peu dans le meilleur des cas. On parle alors « software entropy » ou « vieillissement prématuré du logiciel », en raison de la difficulté croissante des équipes internes à comprendre, à corriger et à faire évoluer lapplication concernée. Un phénomène renforcé ces dernières années par un taux de 6© Copyright Metrixware, 2009. Tous droits réservés.
  • 7. metrixware Livre Blanc turn-over en incessante augmentation et le départ en retraite de certains profils hautement spécialisés et qualifiés, comme cest par exemple le cas des cobolistes. Les points à retenir Pour une gouvernance cohérente et efficace de leur patrimoine applicatif, les DSI disposent de trois principaux leviers : la création de valeur, la maîtrise des coûts opérationnels et la fiabilisation de l’informatique. Des axes de travail très adaptés au mode de sous-traitance de la maintenance applicative : La TMA permet de libérer des moyens humains importants, jusqu’alors mobilisés essentiellement sur la maintenance, au profit de projets alignés sur la stratégie et porteurs de valeur pour l’entreprise ; Elle permet également d’accéder à une solution industrielle éprouvée, reposant sur une parfaite maîtrise par le sous-traitant de la maintenance logicielle (normes, processus, référentiels, etc.) ; Enfin, la TMA permet à moyen terme de diminuer les coûts de maintenance applicative, sans pour autant limiter l’activité de correction ou d’évolution des logiciels. 7© Copyright Metrixware, 2009. Tous droits réservés.
  • 8. metrixware Livre Blanc Une concurrence au profit des clients Répondant parfaitement aux problématiques actuelles des directions informatiques, la tierce maintenance applicative est un marché encore jeune. Son potentiel de revenus est donc colossal : selon les estimations du cabinet Pierre Audoin Consultants, il aurait pesé 1 603 millions deuros en 2006 et devrait dépasser les 2 milliards deuros en 2010. Naturellement, de nombreux acteurs se bousculent sur un marché aussi prometteur, comptant bien soctroyer la plus importante part du gâteau. Parmi ces soupirants, on peut distinguer deux catégories dentreprise : les « mastodontes » du service IT. Ayant capitalisé sur le développement (et donc la maintenance) de leurs propres applications, ces « anciens » y voient une perspective de développement complémentaire à leur métier d’infogérance globale et d’intégration d’infrastructures. Outre une avance commerciale certaine sur leurs concurrents (ils sont déjà implantés chez les clients), leur capacité à absorber des TMA conséquentes est lun de leurs meilleurs atouts. Les petites SSII. Sur le marché de la TMA, elles fondent leur stratégie sur leur capacité à se spécialiser par secteur d’activité ou par technologie. Elles proposent ainsi des TMA plus pointues et en parfaite adéquation avec les besoins de leur clients en raison de leur expertise de leur métier ou des technologies quils utilisent. Très porteur, ce marché nen est donc pas moins extrêmement concurrentiel. Pour séduire une clientèle informée et exigeante, les entreprises se sont adaptées en proposant une offre flexible ou tout autre élément différenciateur. La souplesse de l’offre Cest le cœur, pour ne pas dire la raison dêtre, de la TMA. Et largument numéro un des acteurs du marché, surtout comparativement à la prise en charge en interne (par les équipes du client) de la maintenance applicative. Flexible et souple, loffre des acteurs TMA sadapte ainsi aux variations de périmètre et d’intensité des activités de maintenance (notamment corrective, évolutive) sur un parc applicatif d’une année sur l’autre. Une souplesse qui permet au client de moduler sa TMA au gré de ses besoins en disposant de 8© Copyright Metrixware, 2009. Tous droits réservés.
  • 9. metrixware Livre Blanc ressources additionnelles en cas de pic de charge ou dune réduction des effectifs à sa disposition en période creuse. Concrètement, les contrats de TMA intègrent une partie forfaitaire (support aux utilisateurs des applications, corrections, et enveloppe cadrée d’évolutions), et une partie modulable en cours de contrat. Le caractère variable de la durée de la prestation démocratisant par ailleurs la TMA auprès des PME-PMI. Se différencier par l’engagement sur le niveau de service (SLA - PAQ) Signe de maturité du marché de la TMA, les prestataires incluent désormais à leurs offres un engagement quant au niveau de service à atteindre. En contractualisant ces objectifs d’activité, et en les formalisant dans un Plan d’Assurance Qualité, le client s’assure que la disponibilité et la réactivité des équipes TMA seront au moins – et dans la plupart des cas supérieures – équivalentes à celles de ses ressources internes. Cette démarche, suivie tout au long de la prestation, réduit également le risque de non réversibilité, cest-à-dire la perte de connaissance et de compétences du client si la maintenance revenait à sa charge. Par ailleurs, le pilotage des prestations inclue systématiquement des mesures de performance (temps de traitement d’une anomalie ou d’une demande de support, nombre de corrections et d’évolutions traitées, coûts de la production, etc.) permettant aux deux parties de fixer des objectifs atteignables, et ainsi améliorer la qualité de service de manière continue. Les points à retenir La forte concurrence du marché de la tierce maintenance applicative profite largement aux directions informatiques : Une prestation souple et adaptable aux besoins du client ; Un engagement fort sur les résultats à atteindre, permettant de justifier à court terme l’investissement ; Une amélioration incrémentale du niveau de service. 9© Copyright Metrixware, 2009. Tous droits réservés.
  • 10. metrixware Livre Blanc Le paradoxe de la TMA Ayant connu un développement très rapide, le marché de la TMA dispense aujourdhui une offre déjà très mâture : engagements de résultats, pilotage du contrat sur des indicateurs d’activités, mise en place de plan de progrès et d’amélioration continue pour anticiper sur l’évolution du SI, etc. Les directions informatiques sont pour l’heure satisfaites de cette solution. Et pour cause, elle leur permet de libérer des ressources internes coûteuses et peu flexibles au profit des nouveaux projets, d’exiger contractuellement une maintenance applicative performante et de qualité, et enfin de moduler plus facilement un budget IT plus pressurisé d’année en année. Mais de plus près, le tableau nest pas aussi blanc quil ny paraît. La qualité de service ne suffit pas De quoi parle-t-on, au juste ? Qu’y a-t-il derrière le mot « maintenance applicative » si ce n’est des instructions Cobol, des fonctions C++, des classes Java ou des requêtes SQL ? Du code… plusieurs millions de lignes de code qui, pour certaines applications « legacy », ont été maintenues en interne – tant bien que mal – pendant plusieurs dizaines d’années. Un code qui a aussi survécu aux différentes vagues technologiques et corrections successives, certes, mais un code qui s’est complexifié et appauvri en documentation, qui ne respecte plus les derniers standards de programmation ou les nouvelles conventions de nommage. Bref un code devenu trop difficilement maintenable, moins évolutif et dont la connaissance et la maîtrise s’amenuisent au fil des départs en retraite. Ce même code que l’on demande à son prestataire de maintenir, mais dont on ne contrôle pas la qualité ni au début ni pendant la durée du contrat. C’est ici précisément que les conventions de service actuellement mises en place atteignent leurs limites, car elles encadrent la qualité de la prestation et non la qualité du livrable lui-même. Elles engagent le prestataire à maîtriser et améliorer la production, et non le produit. Elles permettent d’établir des constats a posteriori, et non d’anticiper sur d’éventuelles dérives ou risques techniques. Un contrôle et un suivi de la qualité intrinsèque des composants applicatifs pourraient pallier ces limites. Car en fin de contrat (transfert vers un autre prestataire ou ré-internalisation de la maintenance), c’est bien au produit auquel les équipes de maintenance auront à faire au retour de l’application. Auquel cas, une dégradation de la qualité du code (conformité, maintenabilité, capacité à 10© Copyright Metrixware, 2009. Tous droits réservés.
  • 11. metrixware Livre Blanc supporter de nouvelles évolutions, etc.) augmenterait sensiblement le risque de non- réversibilité. Risque qui, pour rappel, a longtemps freiné les directions informatiques dans leur volonté d’externaliser les activités de développement. 3 questions à... Georges Montoya, Directeur Outsourcing de Logica Logica, acteur européen majeur des services informatiques, a retenu, dans le cadre de son plan industriel, la solution d’Application Portfolio Management System Code de Metrixware pour l’ensemble de ses Centres de Services, et propose à ses clients une amélioration proactive de la qualité et de la performance de ses développements applicatifs. En quoi la qualité du code délivré est-elle un élément important pour vos clients ? Pour quelles raisons ? Depuis plusieurs années déjà, nos clients grands comptes sont sensibilisés et informés quant à la qualité de service et des process en matière dexternalisation des activités informatiques. Ils connaissent et ont su relever le défi du CMMI (Capability Maturity Model & Integration). La qualité du code produit, qui a un impact direct sur leurs coûts de développement et de maintenance IT, est létape suivante. Ainsi, de plus en plus dappels doffre contiennent des SLAs (Service Level Agreement) impliquant directement la qualité du code. Cette qualité technique exigée, gage de maintenabilité et dévolutivité, vise à réduire les coûts sur le moyen et le long terme : bien « écrite », une application se montrera plus fiable, et moins coûteuse à maintenir et à faire évoluer. Pour Logica, les outils de mesure et danalyse de la qualité du code applicatif sont aussi un élément différenciateur sur le plan concurrentiel, tant pour la fiabilisation de nos chiffrages en avant-vente que pour largumentation de nos actions préventives en phase dinitialisation de projets de TMA. Quels processus avez-vous mis en place pour la mesure et lanalyse de la qualité du code applicatif géré par vos centres de services ? Début 2007, nous avons créé une cellule spécifique baptisée Software Quality Center (localisée dans notre Centre de Service Gironde), qui réalise des audits qualimétriques des projets à la demande. Ainsi, sur un projet de maintenance, l’analyse d’une application, à intervalles réguliers, permet d’identifier les dérives de qualité du code produit avant que celles-ci ne deviennent critiques. Il est alors possible d’ajuster les bonnes pratiques internes diffusées auprès des développeurs en vue d’améliorer la qualité de leur travail au quotidien. .../... 11© Copyright Metrixware, 2009. Tous droits réservés.
  • 12. metrixware Livre Blanc En faisant le choix dune solution APM (Application Portfolio Management), nous avons complètement modifié nos procédures de mesure de la qualité. Auparavant, nous utilisions essentiellement des Plateformes d’Intégration Continue (PIC), basées sur des outils Open Source tels que PMD ou Checkstyle, spécifiques aux nouvelles technologies. Si ces plateformes sont efficaces pour lanalyse quotidienne ou hebdomadaire de la qualité du code produit, elles sont en revanche mono-technologie et napportent quune « micro- vision » de la qualité des composants d’une application. Multi-technologies, les solutions dAPM dispensent une vision plus globale de la qualité du code applicatif. En permettant la consolidation des métriques et la prise en compte de données exogènes, elles fournissent des données quantifiables et précises pour une véritable gouvernance des patrimoines applicatifs de nos clients dans la durée. Outre les gains de productivité immédiats par la mise en œuvre de fonctionnalités d’aide à la maintenance (cartographie, analyse d’impact, etc.), quels sont les bénéfices attendus d’un contrôle qualité en amont des livraisons logicielles ? Dans le cadre de projets de maintenance déjà en place, le contrôle qualité en amont permet danticiper les dérives néfastes à la maintenabilité future et dévaluer précisément le ratio coût / utilité des évolutions correctives et préventives. Pour Logica, cest aussi dans les processus davant-vente dune TMA quune solution dAPM trouve toute sa pertinence. Lanalyse du périmètre applicatif à reprendre permet en effet de quantifier précisément la qualité, la volumétrie et la complexité de celui-ci. Réalisées par notre Software Quality Center, les analyses avant-vente offrent ainsi aux équipes répondant aux appels doffre une vision globale du périmètre applicatif et de construire des argumentaires dautant plus pertinents dans nos propositions commerciales. Elles permettent en outre d’extraire une liste de la complexité de tous les composants de l’application, qui sert alors d’entrant aux abaques de chiffrage pour déterminer la complexité d’un composant impacté par une modification. La charte Cigref-Syntec Informatique « Infogérance et TMA » En 2004, le Cigref (club informatique des grandes entreprises françaises) et le Syntec Informatique (chambre syndicale des SSII, éditeurs et VAD) ont signé une charte récapitulant l’ensemble des bonnes pratiques et recommandations à adopter entre le client (membre du Cigref) et le prestataire (membre du Syntec Informatique). Cette charte « Infogérance et TMA » s’articule autour de 10 orientations fondamentales comme la transparence, le partage des connaissances ou la qualité. 12© Copyright Metrixware, 2009. Tous droits réservés.
  • 13. metrixware Livre Blanc Les recommandations sur la qualité des TMA sont déclinées en deux points dans le chapitre « Suivi et Contrôle » : Qualité de service : garantir la réactivité, la flexibilité et un reporting transparent (notions couvertes et cadrées par les Conventions de Service) Qualité de l’application : maintenir les compétences et la documentation (cartographie, plan de formation, etc.), veiller à la maintenabilité (respect des normes, tests, actions préventive…). La qualité du code, sujet peu évoqué par les acteurs TMA Pourtant, les sous-traitants ne semblent pas encore être force de proposition en la matière. Sur un échantillon constitué de vingt offres de TMA (publiées sur le site internet des prestataires), une seule communique sur l’intégration en standard dans le pilotage de la maintenance une analyse et un reporting réguliers portant sur la qualité du code. Si l’on considère ce chiffre, quelles garanties les directions informatiques ont-elles sur le maintien ou l’amélioration du niveau de maintenabilité, d’évolutivité ou de conformité du code constituant les applications qu’elles ont confiées sur un, trois voire dix ans ? Quelques sociétés, grands comptes du secteur bancaire principalement, ont anticipé et se préoccupent déjà de cette problématique, en incluant dans les conventions de services de nouvelles exigences portant sur la qualité du code. Ces indicateurs qualité conditionnant l’acceptation ou le refus des livraisons du prestataire. Mais force est de constater que les acteurs de ce marché restent en retrait sur le sujet et peinent à proposer d’emblée dans leur offre un engagement sur la qualité du code. Peut- être n’y sont-ils pas encore prêts ? Craignent-ils de « se couper l’herbe sous le pied » ? Sans doute ont-ils aujourd’hui mangé leur pain blanc, c’est généralement le lot d’acteurs d’un marché ayant désormais atteint sa maturité : mieux informés et plus exigeants, les clients leur imposent des engagements sur les produits. Engagements qui se limitaient jusque-là une « simple » qualité de service. 13© Copyright Metrixware, 2009. Tous droits réservés.
  • 14. metrixware Livre Blanc Les risques liés à la qualité du code La qualité du code dépend de plusieurs facteurs quils soient purement techniques, tels que la conformité du code aux bonnes pratiques édictées par la profession, ou annexes. Cest le cas notamment des commentaires de code ou de la documentation de développement : en leur absence, lapplication « tournera » correctement mais sils sont présents, ils faciliteront la maintenance et les évolutions futures. Plus largement, l’absence de contrôle de ces facteurs présente des risques techniques, métiers et financiers importants, comme la réduction de la durée de vie de l’application, la hausse des coûts de maintenance, l’allongement des délais de livraison, l’augmentation du nombre de défaillances. Par ricochet, ces risques, s’ils ne sont pas identifiés et maîtrisés sur le projet TMA, peuvent être perçus par le client comme une dégradation des engagements de service pris par le prestataire (réactivité à une demande, rapidité de traitement d’une anomalie, hausse du risque de non réversibilité, etc.). Maintenabilité Alors que 60 à 80% des budgets de développements sont alloués à la maintenance, la maintenabilité d’une application est un élément prédominant de la qualité du code, et vice versa, a fortiori dans un contexte de tierce maintenance. Ainsi, de la qualité du code (et son maintien dans le temps) dépendra la facilité (ou la difficulté) des développeurs à apporter des modifications dans le code. Plus le code est complexe, plus laborieuse sera la tâche de corriger une anomalie remontée par les utilisateurs. La maintenabilité dépend alors de plusieurs critères liés entre eux et dépendant directement des bonnes pratiques de développement. Complexité du code En programmation, il existe de nombreux chemins techniques pour arriver au même résultat. Et le chemin choisi dans un cas ne sera pas forcément pas le bon pour une autre 14© Copyright Metrixware, 2009. Tous droits réservés.
  • 15. metrixware Livre Blanc application. Néanmoins, il est reconnu que certaines pratiques de développement ont tendance à complexifier la structure technique des applications, rendant sa maintenance plus consommatrice en ressources et en temps. Parmi ces pratiques, on retrouve notamment : Les conditions logiques : les opérateurs logiques de condition sont l’une des principales causes de la complexité des composants. Prévues pour orienter l’exécution d’une application en fonction d’une valeur issue d’un traitement, ces conditions, communément appelées « if », et leurs critères d’aiguillage doivent pouvoir être facilement analysées et comprises par le développeur, pour éviter tout risque de défaillance. Quant à ce quil est courant dappeler les « if imbriqués » (les conditions dirigent l’exécution vers d’autres conditions), cest le cauchemar des équipes de maintenance. Les débranchements : ce sont des « raccourcis » permettant aux développeurs d’appeler une partie du programme et continuer le traitement de l’information. Cet usage augmente la complexité, obligeant le développeur à naviguer d’un programme à l’autre pour suivre la logique d’exécution de l’application. Les débranchements sont assez courants dans les applications « legacy », développées en langage procédural (commande « GOTO » en Cobol, C, Pacbase, etc.). Les inclusions : elles consistent à importer une partie de code (fichiers, classes, programmes, etc.) distante du programme en cours d’exécution (ex : fonction « include » en PHP). L’intérêt de cette pratique est de pouvoir « componentizer » l’application pour réutiliser à la demande des groupes de fonctions, en évitant de devoir développer à nouveau ces fonctions. Néanmoins, ces inclusions favorisent la complexité du code : Le développeur doit vérifier si les traitements du fichier en cours de modification sont compatibles avec les fichiers inclus. Taux de commentaire Afin datténuer un code complexe, les développeurs peuvent utiliser des commentaires. Ces lignes de code non exécutées ont pour fonction dexpliciter la nature, le rôle, les fonctions des programmes développés. Ces commentaires servent de « documentation embarquée » pour le développeur. 15© Copyright Metrixware, 2009. Tous droits réservés.
  • 16. metrixware Livre Blanc Ces informations servent aux développeurs pour la bonne compréhension des composants applicatifs en cours de modification (correction d’anomalies, évolutions, etc.). Sans elles, le développeur maintient « en aveugle » ou se réfère à une documentation du composant souvent obsolète et distante de son environnement de développement. Les points à retenir Le niveau de maintenabilité d’une application influe fortement sur la capacité des développeurs à analyser et comprendre le traitement de l’information réalisé dans le code. Ici, c’est essentiellement le facteur temps qui est en jeu. Plus le code est complexe et pauvre en documentation, plus les activités de maintenance seront longues et coûteuses, parfois source d’anomalies supplémentaire. Les effets économiques constatés sur le patrimoine applicatif d’un faible niveau de maintenabilité du code peuvent être : Hausse du nombre d’anomalies : une hausse de la complexité – et donc une dégradation de la maintenabilité – génère une augmentation du nombre d’anomalies. En effet, une modification du code, alors que le développeur ne peut pas intellectuellement prendre en compte toutes les dépendances techniques (conditions, débranchements, etc.), peut faire apparaître des dysfonctionnements de l’application maintenue dans le traitement de l’information. Allongement des délais de livraison : la modification dun code peu maintenable est une tâche délicate. Et le phénomène s’amplifie d’autant que les demandes de corrections augmentent. Les allers-retours entre le développement et le test sont plus nombreux, le cycle de livraison logicielle s’en trouve ainsi fortement ralenti. Phase de test plus longue : la complexité du code étant mal maîtrisée en phase de développement (prolifération des conditions logiques), les cas de tests seront plus nombreux pour couvrir tous les chemins fonctionnels et ainsi détecter les défaillances possibles. Pénalisation des maintenances évolutives : face à la hausse du nombre d’anomalies et de l’allongement des délais de leur correction, le management est souvent contraint et forcé de limiter les budgets de maintenance évolutive, la priorité actuelle étant d’abord de maintenir opérationnelles leurs applications et de garantir leur fonctionnement normal. 16© Copyright Metrixware, 2009. Tous droits réservés.
  • 17. metrixware Livre Blanc Conformité du code La conformité du code est un facteur essentiel dans la mesure de la qualité d’une application. Le respect des normes de programmation comme des règles d’architecture interne du système d’information sont des leviers significatifs influant sur le niveau de performance, de sécurité, de compatibilité d’une application avec le reste du patrimoine. Respect des standards de programmation Oublié le temps de lamoncellement de briques logicielles indépendantes. Aujourdhui, la notion de système dinformation nécessite de penser linformatique dentreprise dans son ensemble. Cest la raison pour laquelle, quels que soient la plateforme et le langage utilisés, des standards de programmation guident les développeurs dans leur travail. Des standards qui sentendent à deux niveaux. Dune part, un niveau pratique, incluant notamment une convention de nommage pour lensemble des composants de lapplication selon leur nature (classes, méthodes, etc.), mais aussi la présence dinformations de documentation embarquées (commentaires de code) et annexes précises, complètes et à jour. Ainsi construite, lapplication est totalement autonome et peut être prise en main par nimporte quelle équipe de développement ou de maintenance applicative. Dautre part, un niveau technique. Il sagit dans ce cas, pour les développeurs, de se conformer à létat de lart du langage quils utilisent : un ensemble de bonnes pratiques édictées au fil du temps par les concepteurs et/ou utilisateurs des langages, leur garantissant performance et sécurité. Conformité architecturale des composants Qu’elle soit descriptive, prescriptive, fonctionnelle ou purement technique, larchitecture applicative est lorganisation des composants, de leurs connexions et leurs dynamiques, en réponse aux besoins fonctionnels de lapplication et de son évolution dans le temps. A linstar dune équipe de football, dans laquelle chaque joueur, sil dispose de ses propres caractéristiques et atouts, construit une tactique globale et cohérente dans un même but commun à toute léquipe, chaque composant dune application doit pouvoir sintégrer à 17© Copyright Metrixware, 2009. Tous droits réservés.
  • 18. metrixware Livre Blanc son environnement architectural afin de permettre sa compréhension et son éventuelle réutilisation dans dautres fonctions. Tout en étant capable de sinterfacer avec dautres applications. Evolutivité Agrandir une maison de campagne sur un terrain plat et spacieux serait plus aisé que réaliser une extension dans un appartement du centre historique de Paris. En informatique, cest pareil : l’évolutivité d’une application traduit son potentiel à intégrer plus ou moins facilement de nouvelles fonctionnalités. Cet indicateur rend compte des efforts de compréhension, de développement et de tests nécessaires pour implémenter des évolutions majeures, compte tenu de la structure et du niveau de maintenabilité de l’existant. Maintenabilité Au cours de la conception dune application, développer du code purement technique et fonctionnel, nous lavons vu, ne suffit pas. Il sagit, avant même den avoir lidée, de penser les évolutions futures des applications, y compris lors des évolutions. En effet, une application pensée à lorigine pour faciliter sa maintenance, peut très vite se détériorer sans un effort de maintenabilité soutenu au cours des corrections et évolutions successives, engendrant alors des risques danomalies, une maintenance future plus délicate et plus onéreuse et, in fine, un raccourcissement conséquent de lespérance de vie de lapplication. Intégrité de l’architecture logicielle L’architecture d’une application logicielle définit les règles de fonctionnement et de communication entre ses composants. Elle permet de gérer le présent, et surtout d’anticiper l’avenir, en toute agilité. Sa non-conformité au niveau du code (mauvaise utilisation de frameworks, de bus de services SOA, etc.), se caractérise par une adhérence forte entre composants, la prolifération d’exceptions et de cas particuliers, impactant alors de manière notoire les efforts à fournir pour intégrer de nouvelles fonctionnalités. 18© Copyright Metrixware, 2009. Tous droits réservés.
  • 19. metrixware Livre Blanc Code mort Au cours des années de maintenance, il peut exister des portions d’application qui ne sont jamais utilisées, des programmes qui ne sont jamais appelés pendant l’exécution d’une application. Il peut s’agir, par exemple, d’un module automatisant la création et l’impression de courriers papiers à destination des employés de l’entreprise, alors que le mode de communication en interne se réalise exclusivement par e-mail depuis 5 ans. Ce « code mort » n’est pourtant pas exclu du périmètre de l’application à maintenir, et alourdit donc inutilement l’effort de maintenance, et par conséquence le contrat de TMA conclu entre l’entreprise et son prestataire. Une analyse du code applicatif avant son externalisation permet alors la détection des parties non utilisées. Les programmes isolés – ceux qui n’appellent aucun autre programme et qui ne sont jamais appelés par d’autres – peuvent alors être retirés du périmètre de la maintenance, allégeant sensiblement la charge de maintenance estimée souvent sur le nombre de lignes de code. Selon le cabinet Forrester, lélimination du code mort des applications confiées en TMA pourrait réduire jusquà 5% le coût total des contrats. Une économie substantielle si lon considère la part croissante des maintenances dapplications externalisées. Les points à retenir La conformité du code aux normes de programmation et aux règles darchitecture du système dinformation influe sur le niveau de performances, de sécurité, de compatibilité d’une application avec le reste du patrimoine ; Le maintien dun effort dévolutivité tout au long du cycle de vie logiciel, y compris lors des corrections et évolutions confiées en TMA, allonge sensiblement lespérance de vie dune application ; Lidentification et la suppression du code mort réduit sensiblement le coût de la TMA. 19© Copyright Metrixware, 2009. Tous droits réservés.
  • 20. metrixware Livre Blanc Les bonnes pratiques du contrôle qualité des Tierces Maintenances Applicatives Les risques et les conséquences techniques et économiques d’une dégradation de la qualité du code applicatif sont nombreux. Dans un cadre contractuel de TMA, la mise en place d’un contrôle régulier à chaque phase majeure du projet a donc pour objectif l’amélioration de la gestion du risque qualité, pérennisant ainsi l’application sous-traitée et la relation client/fournisseur qui en découle. Encore faut-il que clients et fournisseurs s’entendent sur un référentiel commun, telle par exemple la norme ISO 9126, afin de garantir la fiabilité et l’objectivité des résultats, et ainsi d’obtenir, à coup sûr, l’adhésion du prestataire. Objectivité et neutralité des résultats Pour une fiabilité et une efficacité sans faille du contrôle qualimétrique, les tests doivent impérativement reposer sur une série d’éléments factuels et pertinents dans le contexte de l’application, compris et validés par le client et le prestataire. Les mesures ainsi obtenues étant alors incontestables. A ce titre, clients et fournisseurs peuvent s’appuyer sur les standards du marché pour déterminer ensemble le modèle qualité le mieux adapté à l’application et plus globalement au contexte général du système d’information. Règles de programmation standards C’est le niveau « le plus simple ». Concrètement, il s’agit de s’appuyer sur les règles de programmation standards définies par le marché pour chaque technologie ou langage, pour s’assurer de la qualité des développements dans le cadre d’un contrat de tierce maintenance applicative. Techniquement justifiée, cette méthode de mesure de la qualité est nécessaire mais insuffisante à la pérennité d’une application. 20© Copyright Metrixware, 2009. Tous droits réservés.
  • 21. metrixware Livre Blanc Le modèle qualité ISO-9126 Incluant de facto le respect des règles de programmation standards propres à chaque technologie, le modèle ISO-9126, baptisée « Technologie de l’Information : qualité des produits logiciels », ajoute à la mesure du contrôle de la qualité un certain nombre d’éléments, et notamment en termes de fiabilité, de robustesse, d’évolutivité et de maintenabilité. Chaque caractéristique est elle-même sous-catégorisée de façon à classer une série de métriques, identifiées sur la base de définitions standardisées, selon une arborescence structurée. Objectives et incontestables, ces mesures permettent d’identifier, de façon exhaustive, les points faibles de l’application. Les mesures spécifiques Que le choix du contrôle qualimétrique relève de la veille au respect des règles de programmation standards ou d’un document plus élaboré sur la base de la norme ISO- 9126, la mise en place de tests spécifiques s’avère indispensable pour mesurer de façon efficiente la qualité d’une application en fonction de ses spécificités propres et de son contexte technologique et fonctionnel. A quelle phase du projet contrôler la qualité ? Pour des résultats pertinents et dur ables, le contrôle de la qualité doit intervenir à chaque phase du projet : avant l’appel d’offre, avant la signature du contrat, pendant l’exécution du contrat et avant le renouvellement du contrat. Une méthode qui, si elle semble répétitive, en demeure la plus efficace en termes de leviers d’actions et de décisions qu’elle offre aux responsables informatiques dans le cadre de la mise en place, le pilotage ou le renouvellement de leurs contrats de TMA. Avant l’appel d’offre Préalable à toute réflexion de mise en œuvre d’un contrat de TMA, le test qualimétrique en amont revêt un double objectif : cognitif et pécuniaire. Il permet en effet aux 21© Copyright Metrixware, 2009. Tous droits réservés.
  • 22. metrixware Livre Blanc propriétaires des applications à maintenir de dresser un bilan précis de leur état qualitatif et ainsi, avant même de concevoir l’appel d’offres et de qualifier les réponses inhérentes, d’estimer les charges et efforts de maintenance nécessaires. Pour cela, les décideurs peuvent notamment s’appuyer sur la méthode des points de fonction, construite selon les recommandations de l’IFPUG (International Function Points User Group), qui propose une mesure de la production logicielle basée sur les fonctions utilisateurs, indépendantes du nombre de lignes de code. Ce premier bilan en amont offre en outre l’avantage d’identifier et d’éliminer le code mort qui, comme évoqué précédemment, peut représenter jusqu’à 5% du code applicatif, et alourdir d’autant le coût de la maintenance. Avant la signature du contrat En complément du bilan préalable à l’appel d’offres, un test qualimétrique précédant la signature du contrat de TMA est un moyen efficace de négociation des conditions particulières de l’exécution du contrat, fondé sur une base technique solide. Il permet notamment de définir précisément les objectifs généraux du prestataire mais aussi les seuils de qualité à conserver ou à atteindre pour le maintien de la qualité de l’application sur le long terme, au travers de la définition de QLA (Quality Level Agreement), mesurés tout au long du contrat par de nouveaux contrôles qualimétriques réguliers, et totalement complémentaires aux SLA « classiques ». Pendant l’exécution du contrat Selon le mode d’organisation du contrat, les contrôles au cours de l’exécution du contrat s’effectuent à intervalles réguliers ou lors des livraisons des packages. Ces tests permettent, outre le pilotage du prestataire par des objectifs précis, de valider la conformité des livrables par rapport au niveau de qualité défini au contrat. En cas de non-conformité voire de « dérapage », de nouveaux objectifs à atteindre au cours d’une période donnée permettent de prioriser les actions selon un plan hiérarchisé, afin de rattraper les erreurs ou les omissions, sans risquer de se laisser dépasser par la situation ; ce qui aurait pour conséquence, rappelons le, une baisse de la qualité du code et donc de la maintenabilité et de la durée de vie de l’application à long terme. 22© Copyright Metrixware, 2009. Tous droits réservés.
  • 23. metrixware Livre Blanc Avant le renouvellement du contrat Tout comme avant la signature du premier contrat, les contrôles qualité tout au long de son exécution et un diagnostic qualité global du contrat juste avant son renouvellement sont un véritable levier de négociation pour les clients. En fonction des tendances des indicateurs qualité depuis le début du contrat, les clients peuvent pointer du doigt les éventuels points faibles de la maintenance et insister sur les QLA correspondants dans l’avenant, voire, dans le pire des cas, changer de prestataire de TMA. Obtenir l’adhésion du prestataire Avant toute chose, il s’agit de ne surtout pas considérer le contrôle et le suivi de la qualité du code applicatif comme un « flicage ». Il s’agit au contraire d’assainir les relations entre clients et fournisseurs de TMA, ainsi fondées sur un référentiel commun, objectif et indiscutable de part et d’autres. Pour le client, c’est l’assurance de préserver la maintenabilité, l’évolutivité et la durabilité de son système d’information et de son investissement à long terme, selon des critères standards ou spécifiques à chacune de ses applications. Le prestataire quant à lui peut s’appuyer sur ces contrôles pour mesurer précisément les efforts à fournir et la charge de travail pour chaque application à maintenir, ses engagements étant parfaitement délimités, connus et –forcément- acceptés du client. 3 questions à... Rémy BERTHOU, DSI de SNCF Voyageurs La DSI Voyageurs est en charge de lensemble des systèmes orientés transport de personnes au sein du Groupe SNCF. Récente (2003-2004), sa démarche qualité logicielle sest construite parallèlement au développement de la TMA. Quels indicateurs de qualité du code intégrez-vous au sein de vos projets de TMA ? Au-delà du périmètre des applications dont la maintenance est confiée à un tiers, la DSI Voyageurs du Groupe SNCF a développé un portail qualité global. Il prend en charge lanalyse du code des applications développées, maintenues et gérées par lensemble de nos centres de services, quils soient internes ou externes (TMA). …/… 23© Copyright Metrixware, 2009. Tous droits réservés.
  • 24. metrixware Livre Blanc Bâtie sur un modèle qualité définissant les bonnes pratiques de développement et de maintenance spécifiques aux besoins et contraintes du système dinformation Voyageurs, lanalyse de nos éléments applicatifs fait lobjet dun suivi très régulier, de lordre de deux à trois fois par an. Consignés dans un rapport, les résultats sont ensuite examinés avec les tiers mainteneurs pour identifier les points forts et les points faibles, et ainsi définir ensemble les axes de travail à prioriser dans les mois à venir. Nous avons à ce jour atteint le niveau 2 de CMMi, avec désormais l’objectif de valider prochainement le niveau 3. Ces indicateurs de qualité du code sont-ils contractuels avec vos prestataires TMA ? A lheure actuelle, les engagements de qualité de la part de nos prestataires sont informels. Nos contrats ne prévoient pas de système de bonus/malus en fonction des résultats de nos analyses qualité. Néanmoins, les tiers mainteneurs sont informés de notre démarche visant à allonger le cycle de vie de nos applicatifs et y adhèrent assez naturellement, notamment quant aux priorités que nous fixons après chaque analyse. Cest aussi leur intérêt : plus le code reste « propre », plus lapplication est simple à maintenir et à faire évoluer. Quels sont les premiers retours de ces contrôles qualité pour la SNCF DSI-V ? Lobjectif de départ consistait, bien sûr, à nous assurer de la pérennité de nos applicatifs et, par ricochet, de nos investissements, tout en fiabilisant le service rendu. En conséquence de quoi, les coûts de la TMA se sont stabilisés à un niveau acceptable. Dune maintenabilité et dune évolutivité améliorées, nos éléments applicatifs réclament des besoins en jour/homme sensiblement inférieurs. Tandis quune meilleure facilité dapprentissage réduit considérablement notre dépendance aux équipes de maintenance, apportant ainsi un gain de réactivité conséquent. Quoiqu’il en soit, le marché du logiciel en général, et de la TMA en particulier, désormais à maturité, tend inexorablement vers un contrôle systématique de la qualité des applications, tant sur le plan fonctionnel que technique. Selon un sondage international initié par Metrixware auprès de 88 décideurs informatiques via le réseau social professionnel LinkedIn, 63% d’entre eux analysent la qualité de leurs applications outsourcées à chaque livraison, quelle que soit leur motivation : approuver le livrable (40%), identifier les risques et définir les priorités (30%) ou maintenir à jour leur connaissance de l’application (30%). Une tendance qui n’est pas prêt de s’inverser, 24© Copyright Metrixware, 2009. Tous droits réservés.
  • 25. metrixware Livre Blanc l’informatique, tout comme les autres centres de coût des entreprises, voyant leur budget se réduire, ou au mieux se stabiliser, d’années en années. Les points à retenir La qualité du code d’une application doit s’effectuer selon des critères objectifs, compris et acceptés par les deux parties, pour garantir la neutralité des résultats ; Connaissance de l’application, estimation de charges, conformité aux engagements : le contrôle de la qualité du code trouve sa pertinence à chaque phase du projet ; Le contrôle de la qualité du code est un échange entre partenaires : le client garde le contrôle de son application, tandis que le prestataire s’engage sur des objectifs clairs et précis, ni plus, ni moins. 25© Copyright Metrixware, 2009. Tous droits réservés.
  • 26. metrixware Livre Blanc A propos de Metrixware Depuis 1995, Metrixware, éditeur français de suite logicielle System Code, offre à ses clients des solutions daide à la maintenance, de mesures de la qualité logicielle et de gouvernance leur permettant de disposer de la meilleure visibilité sur létat de leur patrimoine applicatif, afin de fonder leur choix de management sur des éléments factuels et le piloter de manière optimale en regard des enjeux fonctionnels, économiques et techniques. Positionnée sur le marché de l’Application Portfolio Management et de la Gouvernance IT, Metrixware met aujourd’hui en œuvre ses solutions auprès de grands comptes comme BNP Paribas, Generali, Société Générale, CNP Assurances, Banque de France, Alcatel Lucent, Orange Business Services, Caisse d’Epargne, etc. La suite logicielle System Code System Code est la suite logicielle dédiée à la Gouvernance et au Management du Portefeuille d’Applications. Elle permet d’analyser rapidement un patrimoine applicatif existant, et d’en mesurer la qualité et la performance pour mener les améliorations les plus pertinentes. Sur la base des informations centralisées dans son référentiel applicatif, System Code fournit aux différents acteurs informatiques les informations capitales pour anticiper les dérives, gérer les risques et maîtriser l’évolution des applications en regard des enjeux métiers, financiers, technologiques et humains d’une DSI : DSI, Directeur des Etudes : Tableaux de bord de gouvernance et de management du portefeuille d’applications (importance stratégique, technologies, budgets, etc.) Responsable Qualité & Méthodes : Suivi global des objectifs de qualité et de conformité du parc applicatif (maintenabilité, évolutivité, architecture, respect des standards, etc.) Responsable d’Applications : Pilotage des indicateurs clés de performance d’une application (qualité, budgets, satisfaction utilisateurs, criticité, etc.) 26© Copyright Metrixware, 2009. Tous droits réservés.
  • 27. metrixware Livre Blanc Equipes de Développement et de Maintenance : Fonctionnalités d’aide au développement (cartographie, analyse d’impact) et de contrôle qualité (règles de programmation, qualité du code) directement intégrées dans l’environnement de travail, à travers les plugins SC for Eclipse et SC for Mainframe. Pour plus d’information sur la solution System Code : www.metrixware.com Le Centre d’Audit Metrixware Le Centre d’Audit Metrixware repose sur une méthodologie outillée utilisant la solution de mesure et d’analyse de code System Code. La puissance de cet outil, associée à l’expertise de nos consultants, permet de dresser un diagnostic complet de la qualité du code d’une ou plusieurs applications, et ce, en prenant en compte leur caractère hétérogène (multi-langages, mainframe et nouvelles technologies, etc.). Une visibilité sur la qualité et les risques applicatifs Cette démarche industrialisée fournit aux Directions Informatiques, au Management et aux équipes opérationnelles toute la visibilité sur leur patrimoine applicatif pour identifier, mesurer et prioriser les risques et les faiblesses de leurs applications : Maintenabilité : Facilité pour les équipes de développement à maintenir une application en conditions opérationnelles (compréhension du code par rapport à sa complexité et sa structure). Evolutivité : Potentiel technique d’une application à supporter des évolutions majeures, de par sa structure, son niveau de maintenabilité. Détection du code mort Conformité du code aux standards de programmation 27© Copyright Metrixware, 2009. Tous droits réservés.
  • 28. metrixware Livre Blanc Respect des règles d’architecture Détection de mauvaises pratiques Une démarche simple et rapide à mettre en œuvre Autrefois complexe et onéreuse à mettre en place, la qualimétrie applicative semblait réservée aux grands groupes. Metrixware la rend désormais accessible à tous avec Insite SaaS. Toute première solution on demand de mesure de la qualité du code applicatif, élément incontournable à la fiabilité, la maintenabilité et lévolutivité des applications dentreprise, Insite SaaS, présentée sous la forme dun tableau de bord complet, est disponible depuis nimporte quel poste connecté à Internet. Elle sappuie sur le modèle qualité standard proposé par Metrixware pour lensemble de ses applications ou sur un modèle spécifiquement conçu pour chaque entreprise. Des livrables exploitables par le management et l’opérationnel Ventilées par application, les informations recueillies par Insite SaaS sont disponibles selon plusieurs niveaux : vue densemble, maintenabilité et fiabilité. En quelques clics, les DSI et responsables informatiques mais également les responsables fonctionnels prennent ainsi conscience très rapidement et très facilement de lensemble des risques technologiques liés à leurs applications, afin de mettre en œuvre les plans dactions nécessaires à leur réduction. Pour une réactivité et des échanges plus sûrs et plus simples entre les nombreux intervenants sur une même application, chaque composant des tableaux de bord dispose dune zone de commentaire interactive. Un mode collaboratif qui sied parfaitement au mode de fonctionnement des entreprises daujourdhui. Pour plus d’information : sur le Centre d’Audit : www.metrixware.com sur Insite SaaS : http://insite.metrixware.com 28© Copyright Metrixware, 2009. Tous droits réservés.
  • 29. metrixware Livre Blanc Copyrights Ce document est la propriété de la société Metrixware et ne saurait être modifié ou diffusé sans son autorisation. 29© Copyright Metrixware, 2009. Tous droits réservés.
  • 30. metrixware Livre Blanc Contacts Marketing & Communication Michael MULLER | METRIXWARE michael.muller@metrixware.com Tél: +33 1 55 69 32 24 metrixware Tél. : +33 1 55 69 32 20 | Fax : +33 1 46 69 08 32 87, Avenue François Arago | 92017 Nanterre cedex, France E-mail : contact@metrixware.com | www.metrixware.com 30 mesurez | maîtrisez | optimisez votre portefeuille d’applications© Copyright Metrixware, 2009. Tous droits réservés.

×