Because Good Software Means Business Performance

Présentation au sujet: "Because Good Software Means Business Performance"— Transcription de la présentation:

1 Because Good Software Means Business Performance
Résultats de l’assessment Qualité de l’application efluid Because Good Software Means Business Performance CAST Application Intelligence Platform 7.0.4 Juillet 2011 CAST Copyright 2007

2 Bilan quantitatif et qualitatif (Facteurs de santé ISO)
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 Copyright CAST 2010

3 CAST : Chef de file de la qualité logicielle des SI
Une mission ambitieuse « Permettre aux entreprises de gagner en efficacité métier en tirant le meilleur parti de leur système d’information. » Des fondations solides 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) Une technologie innovante CAST est un éditeur français, pionnier de la qualité logicielle Cast est une société indépendante créée en 1990, financièrement stable, qui vise à continuer à développer des technologies innovantes comme il l’a fait depuis des années. L’objectif de CAST est d’aider les entreprises à améliorer leur performance métier en les aidant à livrer au business des applications d’excellente qualité (logicielle) Cast est devenu le leader sur le marché de l’intelligence applicative Sa technologie est unique, plus de 55M€ d’investissement cumulé en R&D. + 5M€ par an en développement Présent en France bien sûr, mais aussi au Royaume Uni, en Allemagne, en Italie, en Espagne, en Belgique, aux Etats-Unis et dans d’autres pays via des revendeurs. 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) CAST Copyright 2007

4 Acteur reconnu, bénéficiant d’une forte présence sur le marché
Les analystes et institutions cautionnent CAST Les intégrateurs utilisent CAST Plus de 650 entreprises font confiance à CAST Caution des Analystes: La solution CAST est reconnue par les principaux analystes comme le leader sur le marché des solutions de qualité applicative. L’OMG et le SEI, 2 organisations mondiales auteurs de standard dans le domaine des logiciels comme le CMM, reconnaissent également CAST. Elles sont d’ailleurs à l’origine de la création du CISQ (Consortium for IT Software Quality) dont l’objectif est de définir une nouvelle norme de qualité logicielle pour l’informatique de gestion. Engagement des intégrateurs: les plus grandes SSII européennes et mondiales tels que Accenture, IBM, Capgemini, CSC et Sopra utilisent CAST pour apporter plus de valeur à leurs clients et construire avec eux une relation durable basée sur des mesures objectives de la qualité logicielle et une meilleure performance des équipes de développement. Large liste de clients: plus de 650 sociétés de premier ordre, dans tous les secteurs (finance, telecom, transport, industrie, aéronautique, secteur public), utilisent CAST pour optimiser la qualité logicielle de leurs applications stratégiques, améliorer leur performance et réduire leurs couts IT. CAST bénéficie d’un taux de renouvellement de maintenance très élevé. CAST Copyright 2007

5 La visibilité sur ces systèmes stratégiques est très limitée
CAST Application Intelligence 31/03/2017 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? Est-ce… Un applicatif de mauvaise qualité… Product Pricing Application Dangereux et source d’incidents Difficile à faire évoluer Difficile à comprendre Coûteux à maintenir Équipes de développements internes et sous-traitées …ou… …Conçu selon les règles de l’art et de bonne qualité Product Pricing Application Account Management System Fiable et robuste Facile à faire évoluer et à appréhender Facile à maintenir … Et moins coûteux ! CAST helps management generate insight into the quality of their applications and the performance of their ADM teams The teams may be in one place, multi-sourced, or fully outsourced. The questions remain the same: What are we, as management or business stakeholders, getting from development? How can we go beyond statistical “black box” testing to ensure the applications are well built? Note: Systems listed here are fictitious, intended to represent typical corporate IT applications Customer Information System Account Management 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 Copyright CAST 2007 CAST Copyright 2007

6 CAST : visibilité pour une meilleure performance opérationnelle
1 Arbitrages : Qualité des applications vs. criticité métier 2 Contrôle des tendances : taille et santé des applications 5 3 Causes d’une éventuelle interruption de service 1 2 4 Diagnostic et risques majeurs par application CAST apporte au top management, au project management, aux leaders techniques, architectes et DBAs, ainsi qu’aux développeurs, toute la visibilité et les systèmes de mesure nécessaires à la livraison d’applications de bonne facture. La qualité logicielle s’apprécie via l’analyse systémique (analyse d’un sous-ensemble du SI dans son contexte) qui fournit une note générale s’appuyant sur des agrégats de détails, et permet la détection de problèmes à caractère exceptionnel susceptibles de générer des bugs en production. Complètement automatisée, CAST AIP audite le code pendant la phase de build, et le compare aux meilleures pratiques Comparable à des milliers de code-reviewers qui sauraient tous comment chaque élément de nouveau code interagit avec le reste du système. Grâce à CAST, les organisations IT gère pro-activement la qualité de leurs applications et leurs risques business: 1- Qualité des applications vs. criticité métier: arbitrages documentés sur un parc applicatif, entre objectifs de service, priorités, et risques 2- risques, progrès et évolution d’un projet: prédire les couts, les tendances, et les impacts business du cycle de vie de l’application, en fonction de l’évolution des caractéristiques de l’appli 3- Causes d’une éventuelle interruption de service: plus d’application dont le code est une « black box » ; facilite le dialogue avec les équipes de dév et permet de gérer pro-activement le risque 4- diagnostiques de santé: évaluations régulières d’une application en fonction des objectifs de qualité, pour identifier et prioriser les actions correctives au plus tôt, et éviter un retravail onéreux. 5- Principales caractéristiques des applications: examiner les tendances des caractéristiques qualitatives et quantitatives pour identifier les axes d’amélioration en terme de méthodes, outils, process ou formation L’analogie avec tout autre système d’ingénierie est aisée et archi prouvée. Un bon système (techniquement parlant) – une voiture, un avion ou une application de gestion de facturation – est un système bien construit globalement (les ouvriers ont fait globalement du bon boulot) et qui est exempt du petit détail qui peut envoyer un système ‘parfait’ dans le mur. L’analyse tendancielle est propre aux systèmes d’information puisqu'ils sont en évolution constante, et permet d’introduire la notion de people performance mgnt. 5 Principales caractéristiques des applications 3 4 CAST Copyright 2007

7 La Plateforme CAST d’Application Intelligence
La Transparence, Automatisée! 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 Avoid problems, introduce metrics, do more with less! CAST takes source code delivered by the development teams and processes it to gain a collective understanding of the entire application. Automating the measurement and management of the development process and the quality of its outcome helps the IT organization do more with less. Especially with more pressure on limited resources, and the advent of Agile methodologies, the shorter release cycles render it critical to have an automated system for continual QA. It is important to note following points about the value of the CAST AI Platform: Automated analysis of entire application – with relatively little setup, you can analyze a multi-tiered, multi-technology application of any size and complexity Immediate, unbiased quality assessment – all components of the application automatically get measured on six “health factors” that can be the basis for discussion about quality Executive level of synthesis & trending – all information is synthesized to one score per application, or a metric per component, with easy baselining and trending between releases Drill down to root cause in the source code – any metric or score can be drilled down into, so as to understand the compliance issues or defects that affect that metric Améliorez la qualité en réduisant les coûts CAST Copyright 2007

8 Une analyse en profondeur de la qualité logicielle
Métriques Qualité Indicateurs Qualité Facteurs de Santé Qualité Applicative SQL Complexity Distribution Plus de 800 contrôles qualité et d’architecture Class complexity (Inh. depth) Complexité Performance Class complexity (Inh. width) Artifacts having recursive calls Impact Immédiat Method complexity (control flow) Robustesse Multiple artifacts inserting data on the same SQL table Architecture Coupling Distribution Securité File conformity Dead code Qualité Applicative Structuredness Pratiques de Programmation Controled data access Empty code Modularity Encapsulation conformity Conventions de Nommage Inheritance This is just giving you a little more and I am just going to spend a little more time on these health factors (point out immediate impact factors). This is just a subset of the type of information CAST is looking at correlating it with these quality indicators which then have certain weightings against these heath factors. We’re going to be looking at some screen shots and when we look at the screenshots the measurements we’re using are ISO standard measurements on a scale from 1-4, 1 being bad 4 being good so when we talk about these quality indicators whether is complexity metrics, we’ll have certain weightings on each of these factors, some higher than others…same with Architecture, same with programming practices, etc. When we look at Performance it’s all about identifying potential bottlenecks, am I going to have any scalability issues down the road. The robustness it’s all about stability so what is my risk of failure in production risk, and if I go into the code what is the risk of the code breaking when I want I expected less? Security is all about security breaches which obviously nobody wants to deal with the risk associated with that. These 3 factors are giving you immediate value so if you manage them and clean up the code along the rode you will be basically reducing production defects, reducing performance and security issues before they get released in production. If you look at the bottom three, Transferability is telling you how easy it is to transfer an application to a new team, or new member of the team or even transferring it to an outsourcer. How well written how well it’s documented or follows standards and naming conventions, frameworks. Changeability is giving you a measure of the agility of the application, how quickly can you respond to the market needs, how well written is this application so that I can respond quickly to the market needs? And Maintainability, how likely is that maintaining this app will cost me an arm and a leg down the road. So watching out for Maintainability drifts. As you manage and clean these problems up you get greater and greater value down the road, it becomes more easier to transfer, easier to change, and easier to maintain. The CAST health factors measure the quality risk in an application. CAST provides an out-of-the-box synthesis of the body of Software Engineering knowledge of Software Quality. The six health factors are generic quality indicators, following the ISO model of software quality definition (the same for every language) and specific quality metrics (unique by technology). The only way to get a true measure of quality risk, and an early warning sign before serious problems occur with the application, is to measure quality metrics at the DNA level – directly from the application source code. We automate the process of code review, providing 100% architectural and code checking via our Application Intelligence Platform. Review of Health Factors: 1. Performance - Potential bottlenecks and scalability issues 2. Robustness - Risk of failure, difficulty to test 3. Security - Likelihood of breaches 4. Transferability - Ease of moving code among team members 5. Changeability - Ease of modifying, implementing new features 6. Maintainability - General measure of ease to maintain Package naming Class naming Transferabilité Interface naming Documentation Package comment Class comment Evolutivité Impact à moyen terme Method comment Package size Taille Class size (methods) Maintainabilité Interface size CAST Copyright 2007

9 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

10 Graduation homogène et uniforme du risque qualité
Risque très faible 4 Identification simple, immédiate et uniforme du degré de risque dans tout le portail CAST : Pour une application Pour un module Pour un composant Risque faible 3 Risque élevé 2 La note de 3 est le seuil en dessous duquel le risque devient élevé et les coûts augmentent Risque très élevé 1 Copyright CAST 2011 CAST Copyright 2010

11 Bilan quantitatif et qualitatif (Facteurs de santé ISO)
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 Copyright CAST 2010

12 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 habitants CGI est la quatrième entreprise de services en technologie de l'information en Amérique du Nord plus de professionnels plus de 100 bureaux dans le monde répartis sur 4 continents 24 pays intervenant auprès de plus de 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.

13 Bilan quantitatif et qualitatif (Facteurs de santé ISO)
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 Copyright CAST 2010

14 Points Clé 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

15 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 kLoC, efluid est une application J2EE/Oracle de taille considérable. Elle contient en tout Classes Java. La complexité totale de l’application efluid est de points de décision (équivalent au nombre de cas de test) ce qui en fait une application très difficile à tester. La Techniqual Quality Index est un indicateur unique permettant d’évaluer la difficulté / facilité de maintenir une application à l’avenir

16 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.

17 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 Zoom Efluid : ITV_Efluid est le system qui contient le plus de violations critiques. Copyright CAST 2010 CAST Copyright 2011

18 L’indice de qualité technique pour efluid
Modules dominant Techno dominante 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 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).

19 L’indice de qualité technique pour AEL
Module dominant Techno dominante 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. L’indice de qualité technique de la partie Base de données est le plus à risque

20 Bilan quantitatif et qualitatif (Facteurs de santé ISO)
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 Copyright CAST 2010

21 Robustesse : la gestion des exceptions doit être sécurisée.
efluid : AEL: EDK : ARCHI: 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. 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: 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 Copyright CAST 2010 CAST Copyright 2011

22 Robustesse : Illustration d’une erreur mise à la trappe.
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. Copyright CAST 2010 CAST Copyright 2011

23 Robustesse / Sécurité : Gestion des couches
efluid ael 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 Copyright CAST 2005 23

24 Architecture - Accès à la base de données
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. Insertion Modification Suppression

25 Les dépendances cycliques rigidifient la structure du programme
efluid edk archi ael 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 ael Copyright CAST 2005 25

26 Bonnes pratiques de l’orienté objet
efluid edk ael archi 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

27 Performance: la gestion des boucles doit être optimisée
efluid : AEL: EDK : ARCHI: 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. Instanciation dans les boucles efluid: 1,87% (1 186 / ) 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 / ) des éléments en défaut Appel à une méthode dans la condition de terminaison d’une boucle efluid: 0,63% (394 / ) 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 Concaténation de chaine de caractère sans buffer dans une boucle efluid: 0,06% (40 / ) 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 / ) des éléments en défaut 3 appels à des requêtes SQL dans des boucles relevées pour l’application efluid Copyright CAST 2010 CAST Copyright 2011

28 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.

29 Performance : Requête SQL
efluid ael 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 Copyright CAST 2005 29

30 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.

31 Bilan quantitatif et qualitatif (Facteurs de santé ISO)
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 Copyright CAST 2010

32 Copier-coller et factorisation de code – EFluid et AEL
Très bon taux de réutilisabilité (>=15%) Maintenir la tendance Beaucoup du copiés collés Réutilisation de 18,11 % AEL Taux de réutilisabilité insuffisant (<15%) Attention à la duplication de code Beaucoup du copiés collés Réutilisation de 9,53 % Il faut noter qu'en règle générale la factorisation des composants tend à réduire les coûts de maintenance applicative

33 Copier-coller et factorisation de code – EDK et Archi
Très bon taux de réutilisabilité (>=15%) Maintenir la tendance Beaucoup du copiés collés EDK Réutilisation de 18,45 % Taux de réutilisabilité satisfaisant (proche de 15%) Attention à la duplication de code Beaucoup du copiés collés Il faut factoriser le code Archi Réutilisation de 11,75%

34 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.

35 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.

36 Transférabilité: volume de Documentation technique
efluid : AEL: EDK : ARCHI: 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 Copyright CAST 2010

37 Bilan quantitatif et qualitatif (Facteurs de santé ISO)
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 Copyright CAST 2010

38 Conclusion 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.

39 Bilan quantitatif et qualitatif (Facteurs de santé ISO)
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 Copyright CAST 2010

40 Documentation – Javadoc efluid (1/4)

41 Documentation – Javadoc AEL (2/4)

42 Documentation – Javadoc pour EDK (3/4)

43 Documentation – Javadoc pour ARCHI (4/4)

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

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

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

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

48 Performance – Gestion des boucles pour efluid et AEL

49 Performance – Gestion des boucles pour EDK et ARCHI

50 Architecture – Appel cyclique entre package
Eviter les appels cyclique entre packages : Un est inutilisable sans l’autre Reconcevoir si nécessaire

51 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

52 Architecture – Factorisation – Application
EFLUID Très bon taux de réutilisabilité (>=15%) Maintenir la tendance Réutilisation de 18,11 % AEL Taux de réutilisabilité insuffisant (<15%) Attention à la duplication de code Réutilisation de 9,53 % Il faut noter qu'en règle générale la factorisation des composants tend à réduire les coûts de maintenance applicative

53 Architecture – Factorisation – EDK et Archi
Très bon taux de réutilisabilité (>=15%) Maintenir la tendance EDK Réutilisation de 18,45 % Taux de réutilisabilité satisfaisant (proche de 15%) Attention à la duplication de code Il faut factoriser le code Archi Réutilisation de 11,75%

54 Copier- Coller - EFLUID
Beaucoup de duplication de code à noter au sein de l’application Il faut factoriser le code

55 Beaucoup de duplication de code à noter au sein de l’application
Copier- Coller - AEL Beaucoup de duplication de code à noter au sein de l’application Il faut factoriser le code

56 Copier-Coller – HermesArchi et EDK

57 Répartition de la complexité cyclomatique - EFLUID
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.

58 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.

59 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.

60 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.