L’application dispose actuellement d’une maintenabilité moyenne (note : 1,7 sur 3), traduisant une acceptation pour ce facteur, mais avec les réserves suivantes :

• L’homogénéité de l’application est moyenne à cause du non respect de certaines règles de programmation (notamment concernant la gestion des exceptions) et d’architecture.
• La simplicité du code est fortement dégradée par un nombre trop élevé de méthodes complexes et souvent déstructurées.

La structure en couches n’a pas été respectée à tous les niveaux et il reste encore des parties de l’IHM qui font appel directement à la couche de persistance.

Le tableau ci-contre indique le nombre d’appels incorrects entre les couches de l’application. On peut constater que l’IHM fait 7 appels directs vers la couche de persistance (DB) sans passer par les services métiers.

Nous pouvons utiliser près de 150 métriques, indicateurs objectifs des développements, issues de travaux de recherche professionnels ou universitaires. Celles-ci, applicables aux modèles, au code source ou encore aux tests, se répartissent en plusieurs catégories.

L’analyse par «Rules Checking» vient en complément des métriques. Elle vise à étudier le degré de respect des règles de codage dans un projet.

Applicable à tout type de langage, le Rules Checking permet une grande souplesse quand à la définition des règles à respectées.

Le tableau ci-contre affiche la volumétrie du composant A. On constate un défaut de modélisation des associations dans le sous-composant AB, ainsi qu’un éventuel manque de généricité dû au faible nombre d’interfaces défi nies. De plus, ce composant contient deux attributs publics dont le contrôle d’accés est à justifier ou à réduire.