Because Good Software Means Business Performance

CAST Application Intelligence Platform 7.0.4

Juillet 2011

Résultats de l’assessment Qualité de

l’application

efluid

Agenda

À propos de CAST

Contexte et objectifs

Bilan quantitatif et qualitatif (Facteurs de santé ISO)

Détail des points améliorables Risque en production : Robustesse - Performance

Risque en maintenance : Transférabilité – Évolutivité

Conclusion

ANNEXES

2Copyright CAST 2010

CAST : Chef de file de la qualité logicielle des SI

Une mission

ambitieuse

Des fondations

solides

Une technologie

innovante

« Permettre aux entreprises de gagner en efficacité métier en tirant le meilleur parti de leur système d’information. »

Une présence pérenne en France, en Europe et aux États-Unis

Des partenaires investisseurs long terme

Un investissement en R&D de plus de 80M$

Une équipe visionnaire menée par d’éminents acteurs (CMM, SEI, CISQ)

Précurseur et chef de file d’un nouveau segment de marché depuis 1999

Une expertise unique en qualité et ingénierie logicielle

Editor’s Choice Award: A Top-10 Company to Watch

David Stodder | Editorial Director

Intelligent Enterprise Magazine (TechWeb)

Acteur reconnu, bénéficiant d’une forte présence sur le marché

Les intégrateurs

utilisent CAST

Plus de 650 entreprises

font confiance à CAST

Les analystes et institutions

cautionnent CAST

5 Copyright CAST 2007

Équipes de développements internes et sous-

traitées

La visibilité sur ces systèmes stratégiques est très limitée

Ça fonctionne aujourd’hui, mais savez-vous ce qui a réellement

été produit?

Account Management System

Product Pricing Application

Est-ce…

…ou…

Un applicatif de mauvaise qualité…

…Conçu selon les règles de l’art et de bonne qualité

Customer Information System

Les tests ne permettent pas toujours d’identifier la cause d’un problème ou sont trop coûteux et se produisent trop tardivement

Product Pricing Application

Account Management System

Dangereux et source d’incidents

Difficile à faire évoluer

Difficile à comprendre

Coûteux à maintenir

Fiable et robuste

Facile à faire évoluer et à appréhender

Facile à maintenir

… Et moins coûteux !

Arbitrages :

Qualité des applications vs. criticité métier

1

Contrôle des tendances : taille et santé des

applications

2

Causes d’une éventuelle interruption de

service

3

Diagnostic et risques majeurs par application

4

1 2

3 4

5

CAST : visibilité pour une meilleure performance opérationnelle

Principales caractéristiques

des applications

5

La Plateforme CAST d’Application Intelligence

Analyse automatisée de la globalité d’une application

Bilan Qualité objectif, immédiat et répétable

Vision synthétique pour le Management IT

Mise en lumière des causes des défauts

Aide à la correction via la documentation technique

Améliorez la qualité

en réduisant les coûts

La Transparence, Automatisée!

Une analyse en profondeur de la qualité logicielle

Transferabilité

Evolutivité

Robustesse

Performance

Taille

Conventions de

Nommage

Documentation

Architecture

Complexité

Package naming

Class naming

Interface naming

Package comment

Class comment

Method comment

Package size

Class size (methods)

Interface size

Class complexity (Inh. depth)

Class complexity (Inh. width)

Artifacts having recursive calls

Method complexity (control flow)

Maintainabilité

Securité

Pratiques de

Programmation

File conformity

Dead code

Controled data access

Structuredness

Modularity

Encapsulation conformity

Empty code

Inheritance

Impact Immédiat

Qualité Applicative

Impact à moyen terme

Plu

s d

e 8

00 c

on

trô

les

qu

alit

é et

d’a

rch

itec

ture

Facteurs de SantéIndicateurs QualitéMétriques Qualité Qualité Applicative

Multiple artifacts inserting data on the same SQL

table

Coupling Distribution

SQL Complexity Distribution

Qualifier la qualité selon les standards

Facteurs Description Valeur pour l’entreprise

Transférabilité Mesure de l’effort pour transférer l’application vers une nouvelle équipe interne ou externe ou vers un nouveau membre au sein de l’équipe actuelle

Une meilleure transférabilité contribue à : Eviter la dépendance vis-à-vis d'une ressource interne

ou d’un sous-traitant. Améliorer la productivité d’une équipe Faciliter le transfert entre un sous-traitant et une

structure interne ou vice versa

Evolutivité Mesure de l’effort pour implémenter une modification (évolution ou correction) au sein d’une application

Une meilleure capacité d'évolution contribue à : Améliorer la facilité et la rapidité de maintenance Améliorer la prévisibilité des livraisons Accélérer le time to market

Robustesse Mesure du risque d’introduire un défaut lors d’une modification de l’application (stabilité) et de l’effort de test (testabilité)

Une plus grande robustesse réduit le risque d‘anomalie de l’application en production et améliore la satisfaction des utilisateurs

Performance Mesure du risque de non-performance actuelle ou future de l’application en fonction de sa conception et de son architecture

Une meilleure note de performances réduit le risque qu’une application consomme trop de ressources en production et améliore sa capacité de montée en charges (scalabilité)

Sécurité Mesure du risque de faille potentielle de la sécurité d’une application

De meilleures valeurs de sécurité diminuent les risques d'atteinte à la sécurité de l'application

Maintenabilité Détermine le coût et la difficulté / facilité de maintenir une application à l’avenir

Un meilleur indice de maintenabilité diminue le coût de maintenance des applications

Graduation homogène et uniforme du risque qualité

Identification simple, immédiate et uniforme du degré de risque dans tout le portail CAST :

Pour une application

Pour un module

Pour un composant

10 Copyright CAST 2011

1

2

3

4Risque très faible

Risque faible

Risque élevé

Risque très élevé

La note de 3 est le seuil en dessous duquel le risque devient élevé et les

coûts augmentent

Agenda

À propos de CAST

Contexte et objectifs

Bilan quantitatif et qualitatif (Facteurs de santé ISO)

Détail des points améliorables Risque en production : Robustesse - Performance

Risque en maintenance : Transférabilité – Évolutivité

Conclusion

ANNEXES

11Copyright CAST 2010

Contexte et objectifs

UEM est la première régie indépendante française d'électricité. Elle dessert 142 communes dont la principale est la ville de Metz.

Elle emploie 500 agents au service de 284 000 habitants

CGI est la quatrième entreprise de services en technologie de l'information en Amérique du Nord

plus de 25 500 professionnels

plus de 100 bureaux dans le monde répartis sur 4 continents

24 pays

intervenant auprès de plus de 3 500 clients.

ERDF souhaite étudier l’extension de l’acquisition du progiciel efluid, une application de gestion clientèle et facturation développée par UEM avec la collaboration de son partenaire CGI.

L’analyse de l’application efluid comprend: efluid : Application intranet de gestion clientèle.

AEL : L’agence en ligne accessible via internet.

ARCHI et EDK : les frameworks (composants techniques) maison utilisé par efluid.

Agenda

À propos de CAST

Contexte et objectifs

Bilan quantitatif et qualitatif (Facteurs de santé ISO)

Détail des points améliorables Risque en production : Robustesse - Performance

Risque en maintenance : Transférabilité – Évolutivité

Conclusion

ANNEXES

13Copyright CAST 2010

Le risque qualité est globalement maitrisé.

Efluid est une application volumineuse et complexe, (attention aux tests de non régressions aussi bien coté TU / intégrateur qu’aux tests fonctionnels / intégrations / recettes coté ERDF).

Actuellement, le code statique nécessite des points d'amélioration pour l'optimisation des performances

Pour assurer une bonne évolutivité et maintenabilité, les erreurs critiques sont à corriger

Points Clé

Aperçu global : Maintenabilité, Volumétrie et Complexité

Le TQI de l’application efluid est à 3,04. La maintenabilité globale est correcte. Pour une bonne maintenabilité, le TQI doit

se situer au dessus de 3.

Avec 1 209 kLoC, efluid est une application J2EE/Oracle de taille considérable. Elle contient en tout 9 113 Classes Java.

La Techniqual Quality Index est un indicateur unique permettant d’évaluer la difficulté / facilité de maintenir une application à l’avenir

La complexité totale de l’application efluid est de 222 909 points de décision (équivalent au nombre de cas de test) ce qui en

fait une application très difficile à tester.

Bilan qualité global (Facteurs de santé ISO)

La qualité est globalement bien maitrisée avec un TQI à 3.

Les facteurs de santé transférabilité et évolutivité sont tout juste satisfaisants (proches de la limite de 3).

La robustesse et la performance sont globalement bien maitrisé, mais certains points clé doivent attirer l’attention.

17Copyright CAST 2010

Où sont mes violations critiques ?

Les violations critiques sont les violations les plus importantes trouvées dans le code.

Ces violations peuvent avoir un impact important sur le fonctionnement en production de l’application et sur la maintenance.

Vu sa taille, Efluid contient le plus de violations critiques, principalement

concentrée en performance.

La concentration de violations critiques est faible avec 1,49 v. critique /

kLoc

Moyenne CAST : 4 v. critiques / kLoc

Vu sa taille, Efluid contient le plus de violations critiques, principalement

concentrée en performance.

La concentration de violations critiques est faible avec 1,49 v. critique /

kLoc

Moyenne CAST : 4 v. critiques / kLoc

Zoom Efluid :

ITV_Efluid est le system qui contient le plus de violations critiques.

Zoom Efluid :

ITV_Efluid est le system qui contient le plus de violations critiques.

L’indice de qualité technique pour efluid

Modules dominant Techno dominante

L’indice de qualité technique du module de Facturation est le plus à risque.

L’indice de qualité technique des modules Archivage et Intervention de efluid a risque

(légèrement sous la limite de 3).

Le module Intervention est celui qui contient le plus grand nombre de lignes de code. Il est talonné par

le module Référentiel d ’efluid qui contient le plus grand nombre d’artefacts.

La technologie dominante est le J2EE.

L’indice de qualité technique pour AEL

Module dominantTechno dominante

L’indice de qualité technique de la partie Base de données est le

plus à risque

Le module Référentiel d’AEL est celui qui contient le grand nombre de lignes de

code et d’artefacts.

La technologie dominante est le J2EE.

Agenda

À propos de CAST

Contexte et objectifs

Bilan quantitatif et qualitatif (Facteurs de santé ISO)

Détail des points améliorables Risque en production : Robustesse - Performance

Risque en maintenance : Transférabilité – Évolutivité

Conclusion

ANNEXES

20Copyright CAST 2010

Robustesse : la gestion des exceptions doit être sécurisée.

21 Copyright CAST 2010

22 blocs catch vide relevés dans efluid et 1 bloc catch vide dans EDK (aucun catch vide dans EDK et ARCHI)

Erreur critique : a corriger en priorité

Des exceptions « génériques » sont rattrapées: 1 668 pour efluid (2,68%) , 255 pour ARCHI (2,48%), 230 pour EDK (2,55%) et 57 pour AEL (2,54%)

L’alerte réelle n’est pas traitée

L’historique des erreurs est perdu dans 90 cas pour efluid, 33 pour AEL, 26 pour EDK et 8 pour ARCH

efluid : AEL:

La gestion des exceptions doit être considérée en priorité. Elle augmente le risque d’erreur non détectée en production.

3 violations liées à la gestion des exceptions sont vérifiées par CAST.

Ignorer des exceptions

Gérer les exceptions de manière générique

Protéger l’utilisateur final de messages techniques indésirables lors d’éventuelles erreurs.

Globalement, les exceptions sont bien gérées. Mais des erreurs isolées doivent être corrigées.

EDK : ARCHI:

Robustesse : Illustration d’une erreur mise à la trappe.

22 Copyright CAST 2010

Une bonne gestion des exceptions est critique aussi bien pour le

maintien opérationnel de la plateforme en production que pour la

maintenance et l’aide à l’identification et la correction de bugs.

La plateforme CAST vous permet d’identifier les éléments à risque et de

visualiser le code source en erreur.

Robustesse / Sécurité : Gestion des couches

23Copyright CAST 2005

Accéder à la base de données par des couches DAO permet de maintenir une couche d’abstraction entre le modèle de donnée et le

code.

Ceci permet d’avoir une application plus modulaire, de contrôler les modifications faites dans les tables, d’éviter les injections SQL,

et d’optimiser les requêtes.

L’étanchéité des couches est bien respectée dans Efluid

efluid ael

efluid ael

L’accès multiple aux tables du a la gestion de la

communication avec la BDD par code généré.

Vu que les requêtes sont encore écrites à la main, CAST

permet de maitriser les évolutions et connaitre toute les

requêtes a faire évoluer lors de changement.

Architecture - Accès à la base de données

Insertion

Modification

Suppression

25Copyright CAST 2005

Les packages permettent de découper son application en modules élémentaires et réutilisables.

Avoir des dépendances cycliques dans les packages rigidifie l’application et empêche la réutilisabilité des packages sans tirer une

grosse grappe de code.

41% des packages de efluid , 52% des packages de ael sont impliqués dans une dépendance cyclique

38% des packages d’ archi , 28% des packages d’EDK sont aussi impliqués dans une dépendance cyclique

Il est conseillé, au fur et à mesure des évolutions, de casser les dépendances cycliques.

efluid edk

Les dépendances cycliques rigidifient la structure du programme

ael archi

efluid

ael

Bonnes pratiques de l’orienté objet

•Fournir des « get/set» pour les variables privées afin de respecter le principe d’encapsulation

•Déclarer des variables comme public expose la classe à des modifications externes

•Pour des raisons de sécurité, il faudrait typer l’accès aux variables déclarées au niveau de la classe

D’une manière générale, ces bonnes pratiques sont bien respectées.

Les valeurs sont données pour efluid, ael, edk et archi dans l’ordre ci-dessous :

• 7,7%, 2,6%, 7,94%, 7,19% des variables privés ne possèdent pas d’accesseur/getteur

• 2,56%, 0%,0,5%, 0,46% des variables sont déclarées public

• 6,7%, 0%, 0,14%, 6,43% des variables ne sont pas typées

efluid edk

ael archi

Performance: la gestion des boucles doit être optimisée

27 Copyright CAST 2010

Instanciation dans les boucles

efluid: 1,87% (1 186 / 63 393) des éléments en défaut

AEL : 0,94% (21 / 2 274) des éléments en défaut

EDK : 0,97% (88 / 9 101) des éléments en défaut

ARCHI : 0,69% (71 / 10 274 ) des éléments en défaut

Appel à une méthode dans la condition de terminaison d’une boucle

efluid: 0,63% (394 / 62 335) des éléments en défaut

AEL : 1,47% (33 / 2 242) des éléments en défaut

EDK : 0,75% (68 / 9 101) des éléments en défaut

ARCHI : 0,69% (71 / 10 274 ) des éléments en défaut

Concaténation de chaine de caractère sans buffer dans une boucle

efluid: 0,06% (40 / 63 393) des éléments en défaut

AEL : 0,13% (3 / 2 274) des éléments en défaut

EDK : 0,04% (4 / 9 101) des éléments en défaut

ARCHI : 0,04% (4 / 10 381 ) des éléments en défaut

3 appels à des requêtes SQL dans des boucles relevées pour l’application efluid

efluid : AEL:

Appels couteux dans les boucles : Performance statique

provoquent des temps de réponse non optimaux dus à la mauvaise gestion du garbage collector

provoquent une utilisation très forte du réseau et de l’accès à la base de données

Consomment parfois inutilement des ressources

Globalement la gestion des boucles pourrait être améliorée.

EDK : ARCHI:

Performance : utilisation de cursor dans les boucles

efluid :

Utiliser des cursors dans des boucles indique une double itération de la table.

Le temps de traitement devient donc exponentiel.

Afin d’optimiser les performances, il est déconseillé d’utiliser des cursors dans des boucles.

1 seule procédure sur les 14 procédures stockées que compte efluid utilise un cursor dans une boucle.

29Copyright CAST 2005

Bien que la BDD soit de petite taille, les bonnes pratiques SQL ne sont pas toujours respectées, ce qui peut engendrer des goulots d’étranglement

de performance de l’application lors de manipulation de données.

Pour ael :

•100 % des tables n’ont pas de clé étrangère ( 8 tables)

•Aucune tables n’utilisent des index redondants (bien)

Pour efluid :

•24 % des requêtes Sql n’utilisent pas d’index (lecture séquentielle de toute les lignes, a croiser avec les volumétries des tables)

•40% des requêtes Sql utilisent des clauses UNION

•12% des requêtes Sql utilisent les requêtes imbriqués

•3,85 % des tables ne placent pas les attributs null à la dernière position (manque d’optimisation)

•6% des tables utilisent des index redondants

efluid ael

Performance : Requête SQL

Comment construire son plan d’action ?

Le PRI (Propagated Risk Index) aide à prioriser les violations en fonction de leurs risques, et du risque de propagation de l’erreur.

Plus le PRI est élevé, plus le risque de déclenchement de l’erreur et de propagation de l’erreur est fort.

Agenda

À propos de CAST

Contexte et objectifs

Bilan quantitatif et qualitatif (Facteurs de santé ISO)

Détail des points améliorables Risque en production : Robustesse - Performance

Risque en maintenance : Transférabilité – Évolutivité

Conclusion

ANNEXES

31Copyright CAST 2010

Copier-coller et factorisation de code – EFluid et AEL

Réutilisation de 18,11 %

Réutilisation de 9,53 %

Très bon taux de réutilisabilité (>=15%)

Maintenir la tendance

Beaucoup du copiés collés

Il faut noter qu'en règle générale la factorisation des composants tend à réduire les coûts de maintenance applicative

EFLUID

AEL Taux de réutilisabilité insuffisant (<15%)

Attention à la duplication de code

Beaucoup du copiés collés

Copier-coller et factorisation de code – EDK et Archi

EDK

Archi

Réutilisation de 18,45 %

Réutilisation de 11,75%

Très bon taux de réutilisabilité (>=15%)

Maintenir la tendance

Beaucoup du copiés collés

Taux de réutilisabilité satisfaisant (proche de 15%)

Attention à la duplication de code

Beaucoup du copiés collés

Il faut factoriser le code

Exemple de Copier- Coller - EFLUID

La duplication de code est déjà vérifiée dans efluid pour les méthodes de plus de

50 lignes.

Complexité applicative

On observe une bonne répartition globale de la complexité cyclomatique

Il est impératif de maintenir cette maitrise pour éviter la propagation de la complexité et les dérives des coûts de maintenance.

Transférabilité: volume de Documentation technique

36 Copyright CAST 2010

La documentation d’Efluid est principalement gérée dans une documentation externe.

Avoir un bon taux de documentation technique améliore la productivité des développeurs, diminue les coûts de maintenance et améliore la transférabilité applicative.

Malgré un taux de documentation élevé d’environ 30%, la répartition de la documentation n’est pas homogène.

La répartition de la documentation technique doit être améliorée:

9,56% des JSP de efuild, 18,18% de AEL, 19,3% de EDK et 30,93% de ARCHI ne sont pas documentées

15,96% des Classes de efluid, 6,98% de AEL, 20,17% de EDK et 7,85% de ARCHI ne sont pas suffisamment documentées

27,09% des méthodes de efluid, 24,49% de AEL, 44% de EDK et 54,35% ne sont pas suffisamment documentées

92,26% des fonctions JavaScripts de efluid, 82,35% de AEL, 81,44% de EDK et 70,91% de ARCHI ne sont pas documentéess

efluid : AEL:

EDK : ARCHI:

Agenda

À propos de CAST

Contexte et objectifs

Bilan quantitatif et qualitatif (Facteurs de santé ISO)

Détail des points améliorables Risque en production : Robustesse - Performance

Risque en maintenance : Transférabilité – Évolutivité

Conclusion

ANNEXES

37Copyright CAST 2010

A la suite de cet audit, CAST a identifié une bonne qualité globale, avec cependant des points clé a surveiller

Vu la globale bonne maitrise de la qualité, un déploiement plus global de efluid peut être envisagé si certaines précautions sont prises

iI reste à nettoyer quelques points clé pour assurer un bon niveau de qualité logiciel et éviter que ces violations ne deviennent une cause de dysfonctionnement ou d'incapacité a atteindre les niveaux de performances attendus

Il faut corriger les violations critiques en robustesse et performance : le risque est potentiellement décuplé avec la futur montée en charge de l’application

Attention a la gestion des exceptions

Mieux respecter les pratiques de programmation objet

Optimiser les boucles et la communication avec la base de données

Utiliser les outils CAST (PRI) pour construire un plan d’action rapide et efficace en les croisant avec des informations de dimensionnement ainsi que le résultats des autres audits.

La génération automatique de code, et la gestion externe de la documentation permettent de sécuriser l’évolution applicative.

Conclusion

Agenda

À propos de CAST

Contexte et objectifs

Bilan quantitatif et qualitatif (Facteurs de santé ISO)

Détail des points améliorables Risque en production : Robustesse - Performance

Risque en maintenance : Transférabilité – Évolutivité

Conclusion

ANNEXES

39Copyright CAST 2010

Documentation – Javadoc efluid (1/4)

Documentation – Javadoc AEL (2/4)

Documentation – Javadoc pour EDK (3/4)

Documentation – Javadoc pour ARCHI (4/4)

Documentation – Répartition sur efluid (1/4)

Documentation – Répartition sur AEL (2/4)

Documentation – Répartition sur EDK (3/4)

Documentation – Répartition pour ARCHI (4/4)

Performance – Gestion des boucles pour efluid et AEL

efluid

AEL

Performance – Gestion des boucles pour EDK et ARCHI

EDK

ARCHI

Architecture – Appel cyclique entre package

Eviter les appels cyclique entre packages

:

Un est inutilisable sans l’autre

Reconcevoir si nécessaire

Bonnes pratiques de l’orienté objet

Quelques conseils pour le respect des bonnes pratiques de la programmation orientée objet :

Fournir un constructeur vide pour les classes utilitaires permet de s’assurer que le développeur utilise ces classes correctement (Empêche le développeur d’instancier une classe qui ne doit

jamais être instanciée)

Fournir des « get/set» pour les variables privées afin de respecter le principe d’encapsulation

Déclarer des variables comme public expose la classe à des modifications externes

Pour des raisons de sécurité, il faudrait typer l’accès aux variables déclarées au niveau de la classe

Architecture – Factorisation – Application

Réutilisation de 18,11 %

Réutilisation de 9,53 %

Très bon taux de réutilisabilité (>=15%)

Maintenir la tendance

Il faut noter qu'en règle générale la factorisation des composants tend à réduire les coûts de maintenance applicative

EFLUID

AEL Taux de réutilisabilité insuffisant (<15%)

Attention à la duplication de code

Architecture – Factorisation – EDK et Archi

EDK

Archi

Réutilisation de 18,45 %

Réutilisation de 11,75%

Très bon taux de réutilisabilité (>=15%)

Maintenir la tendance

Taux de réutilisabilité satisfaisant (proche de 15%)

Attention à la duplication de code

Il faut factoriser le code

Copier- Coller - EFLUID

Beaucoup de duplication de code à noter au sein de l’application

Il faut factoriser le code

Copier- Coller - AEL

Beaucoup de duplication de code à noter au sein de l’application

Il faut factoriser le code

Copier-Coller – HermesArchi et EDK

Répartition de la complexité cyclomatique - EFLUID

Complexité faible Complexité élevée

On observe une bonne répartition globale de la complexité cyclomatique

Il est impératif de maintenir cette maitrise pour éviter la propagation de la complexité et les dérives des coûts de maintenance.

<5%

<3%

Répartition de la complexité cyclomatique - AEL

Complexité faible Complexité élevée

<5%

<3%

On observe une bonne répartition globale de la complexité cyclomatique

Il est impératif de maintenir cette maitrise pour éviter la propagation de la complexité et les dérives des coûts de maintenance.

Répartition de la complexité cyclomatique - HermesArchi

Complexité faible Complexité élevée

<5%

<3%

On observe une bonne répartition globale de la complexité cyclomatique

Il est impératif de maintenir cette maitrise pour éviter la propagation de la complexité et les dérives des coûts de maintenance.

Répartition de la complexité cyclomatique - EDK

Complexité faible Complexité élevée

<5%

<3%

On observe une bonne répartition globale de la complexité cyclomatique

Il est impératif de maintenir cette maitrise pour éviter la propagation de la complexité et les dérives des coûts de maintenance.