La semaine dernière, je vous ai présenté les différents niveaux de maturité en matière de qualité logicielle et comment la mesure de la dette technique nous permet de progresser à travers ces différents niveaux, pour une gestion proactive et optimisée de la qualité.

A cette occasion, j’ai parlé d’utiliser la dette technique dans le cadre de la représentation d’un portfolio d’applications, selon différents axes. Je me suis alors demandé ce que donnerait une représentation 3D d’un tel portfolio, avec le plugin ‘3D City Model’ d’eXcentia (1).

Je vous ai déjà présenté celui lors d’articles précédents : City Model, City Model – Nouvelle version,  Cité Critique, où nous avions vu notamment comment rentrer nos propres formules pour jouer avec ce modèle 3D, et enfin La métrique ABC  afin  d’investiguer la métrique du même nom. Continuer la lecture →

Vous connaissez tous CMMI, je pense ? Ce modèle développé par le Software Engineering Institute prévoit cinq niveaux de maturité afin de mesurer la qualité des services informatiques, ainsi que les bonnes pratiques associées à cette échelle de niveaux et permettant de progresser à travers celle-ci. Je ne vais pas écrire tout un post sur ce modèle, ce n’est d’ailleurs pas le sujet de cet article, mais simplement le présenter comme je pourrais le résumer à quelqu’un qui n’y connaît rien en matière de gestion de projets et de développements d’applications. Continuer la lecture →

Nous nous sommes demandé, dans le post précédent, pourquoi les développeurs ne connaissaient généralement pas les Points de Fonction, et si cette métrique pouvait leur être utile.

Notre réponse est plutôt négative, surtout si l’on considère qu’une telle estimation est réalisée manuellement, par des consultants qui s’appuient sur une démarche assez complexe. Il existe d’ailleurs nombre de certifications dont l’objet est de valider qu’un consultant maîtrise ces concepts et sache les mettre en œuvre de manière opérationnelle. Continuer la lecture →

Le titre de ce post paraphrase le titre d’un roman de science-fiction que vous connaissez peut-être : « Do Androids Dream of Electric Sheep? ».

Cette nouvelle de Philip K. Dick a servi de base au film « Blade Runner » de Ridley Scott, dans lequel un détective du futur doit retrouver et neutraliser des androïdes que rien ne diffère des humains. Continuer la lecture →

Nous avons vu dans le post précédent comment entamer un reengineering avec SonarQube en commençant par un redécoupage fonctionnel et le re-design de notre application.

Nous pouvons maintenant descendre un peu plus dans le code afin d’identifier des flux de traitements candidats à restructuration. Continuer la lecture →

Nous avons défini notre projet de réingénierie comme la réécriture de notre application Legacy dans un nouveau langage ou son portage vers une nouvelle technologie, par opposition à un refactoring qui consiste à réorganiser le code et à en corriger certains défauts afin de rendre celui-ci plus maintenable et de réduire sa dette technique.

Nous avons vu également, à l’aide de SonarQube et du plugin SQALE, différents plans de refactoring plus ou moins ambitieux, depuis la résolution des défauts les plus critiques jusqu’à la réduction de la dette technique afin de ramener celle-ci à un niveau (rating SQALE) ‘A’.

Cependant, pour une même application Legacy, est-il plus intéressant d’effectuer un projet de réingénierie ou ‘simplement’ de refactoring ? Continuer la lecture →

Un reengineering ne signifie pas toujours dans l’esprit de chacun, la réécriture de notre application Legacy dans un autre langage généralement plus récent, mais c’est néanmoins l’option que nous avons choisie.

Lorsqu’il s’agit ‘simplement’ de réorganiser le code afin de rendre celui-ci plus maintenable, mais sans le porter sur une nouvelle plate-forme logicielle ou hardware – comme par exemple la migration d’une application Mainframe-Cobol vers une architecture Unix – je préfère parler de refactoring.

Je vous rappelle que ce blog n’a pas de prétentions académiques, donc je ne vais pas m’embarrasser de définitions méticuleusement exactes, qui débouchent le plus souvent sur des discussions quadripilotectomiques (1) de spécialistes qui n’ont rien d’autre à faire que de gloser sur la moindre virgule. Continuer la lecture →

En matière de ROI, je ne me complique pas la vie : je pose l’hypothèse que nous allons réduire les coûts de maintenance dans une proportion égale à la réduction de la dette technique.

C’est une hypothèse que l’on peut trouver simpliste et donc discutable, mais notre ambition ne réside pas dans une précision absolue et exacte des chiffres que nous avançons – ce serait prétentieux et irréaliste – sinon à fournir au management des éléments qui facilitent sa prise de décision.
Et je pense que le management préfère une hypothèse de travail simple et claire, même si moins précise, plutôt qu’une formule complexe qui ne sera pas forcément plus réaliste. Continuer la lecture →

Comme je l’ai expliqué dans le post précédent, nous n’avons pas personnalisé le profile SonarQube et le modèle SQALE en fonction de notre application Legacy et de son contexte. En fait, nous utilisons les résultats ‘out of the box’ afin d’illustrer une démarche possible d’estimation du coût de refactoring de celle-ci, et de présenter quelques pistes d’action à approfondir avec l’équipe de projet et le management – ou éventuellement à voir ceux-ci les rejeter.

En d’autres termes, c’est la démarche qui nous intéresse plus que les résultats sur notre application, tout au moins dans le cadre de ces articles.

Je vais présenter ces actions, des plus simples au plus avancées. Continuer la lecture →

Afin de procéder à une estimation du coût de refactoring de notre application Legacy, je vais utiliser le plugin SQALE de SonarQube, employé habituellement pour mesurer la Dette Technique.

Nous avons déjà présenté ce plugin avec une application Legacy PL/SQL. Rappelons donc simplement que le plugin SQALE est basé sur le modèle SQALE de la qualité, et j’ajouterai également, sur une méthode permettant d’adapter le modèle en l’alignant avec les différents objectifs métiers, la technologie utilisée pour l’application, ou le contexte applicatif. Continuer la lecture →