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 →