Audit technique de code

8 607 vues

Publié le

Sujet de mémoire : Audit technique de code

Publié dans : Technologie
2 commentaires
14 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
8 607
Sur SlideShare
0
Issues des intégrations
0
Intégrations
89
Actions
Partages
0
Téléchargements
0
Commentaires
2
J’aime
14
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Bonjour Monsieur PIPARDDonc aujourd'hui je vais présenter mon thème de mémoire qui est l’audit technique de code Mais Avant de commencer je voudrais remercier tout le personnel de l’Ecole ESIAG pour avoir assuré une formation de haute qualité.j‘éspèremonsieur , quema présentation sera a la hauteur de votre attenteSans trop tarder je vais passer directement au plan de cette présentation
  • Au début je vais commencer par une introduction ou j’expliquerai les raisons qui m’on poussé a choisir ce thèmeEnsuite je présenterai ce qu’est l’audit technique en générale et puis plus spécifiquement celui du code , j’expliquerai aussi les raisons pour les quels on effectue un audit technique de code, les axes traité par ce dernier, quand l’effectuer et les acteurs concernés.Puis je présenterai les méthodes d’analyses utilisées pour sa mise en place ainsi que voir ce qu’est les modèles de qualité et leurs relation avec ces méthodes d’analysesDans le point qui suis je présenterai ma méthodologie personnelle pour la réalisation de l’audit de code(cette méthodologie répond a l’ problématique traiter par le sujet de mémoire « Qu’elles sont les étapes à suivre afin de mettre en place un audit technique de code »)Finalement je présenterai rapidement la solution que j’ai mis en place au sien d’ALTIEt je terminerai cette présentation par une conclusion
  • Avant de présenter l’audit technique de code je vais déjà définir brièvement ce qu’est déjà l’audit technique en généraleL’audit technique est un outil de contrôle et de conseil qui permet de faire le point sur l'existant une sorted’état des lieux , dans le but d’identifier les points forts et faibles du système étudié et d’Obtenir des solutions et recommandations pour de futurs correction et amélioration des anomalies et problèmes de ce dernier
  • Donc qu’est ce qu’ est au juste L’audit technique de code ?L’audit de code est un processus qui consiste en une analyse et vérification du code sources de l’application.Il est permet d’optimiser le développement et réduire les coûts et délais. Cette audit se base sur des modèles de qualité a respecter qui définissent des règles adaptés aux demandes de chaque client.
  • Alors pourquoi effectué un audit de code ?Comme vous le savez monsieurLa surveillance de la qualité du code des grands projets susceptible d’évoluer dans le temps esttrès importanteVue que de tel projets coutent des millions d’euros et aussi que le cout de correction évolue exponentiellement dans le temps,vue que les lignes de code sont de plus en plus nombreuse et donc de plus en plus difficile a comprendre et a maintenirEt c’est d’ailleurs la que l’audit de code s’impose comme un outil incontournablepour :Optimiser les développements et la maintenance du code applicatifAméliorer la qualité de l’applicationOptimiser la maintenance corrective ou évolutiveAugmenter les performances des applicationsAugmenter la sécurité des applicationsIdentifier et anticiper les problèmes de performance et de sécurité.
  • L’audit technique de code peut traiter différents axes selon le besoin du client, par exemples il peut vérifier si L’architecture logicielle est bien conçu , voir si le système peut s’interfacer et communiquer avec d’autres systèmes externesOu encore vérifier si le code respecte les normes et standard de programmation et des Frameworks utilisés.L’audit de code peut aussi être axé vers les performances afin de mesuré les temps des réponses du systèmeIl peu aussi Mesurer la robustesse, la fiabilité, la scalabilité voir par exemple si le système accepte une monté en charge sans perte de performances (ou encore de vérifier si le systèmes arrive a gérer efficacement les transactions distribués)Vérifier si le système peut facilement accepter des évolutions et de la maintenance par exemple dans le cas du Projet TECK , ONF a attribuer la maintenance du projet a LOGICA plutôt qu’ALTI, l’ONF a donc demandé a ORESYS de réaliser un audit technique de code axé sur la maintenance pour que ALTI effectue les changements qu’il faut.Le client peut avoir aussi comme besoin de Vérifier si la qualité et le pourcentage de présence de la documentation technique est correcte.(Java Doc dans le monde JAVA)L’audit de code peut aussi vérifier les failles de sécurité logique existantes
  • L’audit technique de code est effectué soit lorsque l’entreprise cherche a voir plus claire sur un système ou lorsqu’elle cherche a faire un suivi de code.Dans le premier cas l’entreprise cherche a voir plus claire sur des systèmes de type« boite noire ».cela veux dire des systèmes ou ’entreprise ne dispose quasiment pas d’indicateurs, et souhaites avoir des mesures plus claires sur ce dernier.Dans ce cas l’auditeur doit effectuer une analyse approfondi du code .afin d’identifier le maximum de problèmes et de proposer d’éventuelles solutionsUne telle prestation est destinée pour une prise de décision et demande du temps pour son élaboration. Le deuxième cas c’est lorsque l’entreprise souhaite faire un suivi de qualité de code du projet. Qu’il s’agisse d’un nouveau ou d’un projet pour la tierce maintenance applicative.Dans ce cas, la mise en place d’une PIC et d’une plateforme de suivis de qualité de code est obligatoire afin de pouvoir suivre d’évolution à chaque intervention sur le code source et à chaque livraison.Ce deuxième cas est particulièrement utile dans le cadre de la sous-traitance.
  • Maintenant je vais passer aux acteurs concerné par cet auditAlors L’audit technique de code est effectué soit par une SII soit par un freelanceL’auditeur doit avoir des compétences technique avancées , être spécialiste dans le langage utilisé , avoir des connaissances dans l’architecture de haut niveau et du domaine applicative Mais en plus il doit disposer d’un esprit de gestionnaire et d’organisateur
  • L’audit de code concerne ne concernent pas que les développeurs mais il concerne aussi les décideurs ( chefs de projet et managers)Les développeurs sont les acteurs principaux vue que c’est eux qui implémente les bonnes pratiques de développements et les solutions proposées par les auditeurs et interprète les indicateurs pour effectuer des corrections et des amélioration automatiquement Tandis que les décideurs interprète les résultats de l’audit et prennent des décisions afin de mieux gérer les équipes de développements
  • Bien évidement l’ajout d’un système pareille, impose une conduite de changement vis-à-vis les acteurs et principalement vis-à-vis les développeurs qui voie l’audit comme un moyen de contrôle et de surveillance plutôt qu’un moyen d’amélioration continue.C’est pour cette raison qu’il est très conseillé au début de choisir que quelques règles et de bien les choisir ,afin de laisser aux développeurs le temps de s’habituer au système.Mais aussi de leurs fournir ces indicateurs afin de leurs permettre de se sentir impliquer dans le travail ce qui les pousserais a corriger automatiquement et efficacement les problèmes détectés.I faut expliquer aux développeurs qu’un tel audit ou un tel suivi de qualité de code permet de faciliter le travail , leurs permettre d’éviter des régressions fréquentes et leurs permettre de corriger rapidement les anomalies rencontrées.
  • Une question se pose, Mais en quoi consiste réellement l’audit de code ? L’audit de code consiste a effectué un ensemble d’analyses Ou on va étudie d’une part la manière dont le code est structuré autrement dit sa syntaxe et d’autre part comment le code est exécutéCes analyses s’effectue selon 2 méthodes ,une analyse statique et une autre dynamique
  • l’analyse statique du code est une notion qui permet d’obtenir des informations sur le comportement du programme sans avoir à exécuter ni a compiler le code source. Cette analyse permet de détecter des erreurs de programmation , de conception ,d’identifier des failles de sécurité ,des bugs potentiels , du code suspect, des pratiques risqué ou encore de vérifier si des règles d’écriture et de nommage du code sont respecté.tout cela s’effectue grâce à une analyse et teste de la syntaxe et de sémantique du code sources.
  • Cette analyse a pour objectif d'évaluer la qualité, lesperformances et la sécurité du code sources, mais aussi de déterminer la facilité ou la difficulté à maintenir ce code .ceci avant toute étude du comportemental du code (analyse dynamique).Par exemples avec une analyse statique on peut détecter les erreurs suivantes :des fuites de mémoire et/ou des problèmes de performancedes variables initialiser mais non utiliséesdes failles de sécurité telle que le “buffer overflow” (dépassement de tampon)de la redondance du code (code copié-collé)de trouver des variables déclaré 2 fois.de détecter des zones de code non utiliséede localiser des méthodes privées jamais appelées
  • Tandis que L'analyse dynamique est une notion qui permet de simuler l'exécution du code sources d’un programme sur un vrai processeur ou un processeur virtuel.Afin de révéler des erreurs de codage souvent comportementale qui ne sont pas visible avec une analyse statique du code.Une telle analyse permet par exemples de détecter des problèmes :lors de l’ouverture d’un fichier inexistant.de sécurité système: lorsque l’utilisateur ne dispose pas  de droit d'accès en écriture...pointer vers une adresse mémoire non alloué et/ou non permise par le systèmeL’analyse dynamique fait appels principalement a deux techniques : le débogage et le profiling, c’est mécanismes sont actuellement très utilisées par les développeurs vue leurs utilités.
  • Le Profiling est une technique d'analyse des performances de l’application, elle permet d’offrir des mesures sur la fréquence des appels de méthodes, ou encore la durée de l’appel d’une méthodemais aussi d’identifier les différentes parties critiques du code.Quand a la technique du débogage est une technique qui permet d’exécuter le code source pas à pas avec une possibilité de mise en place de points d'arrêt conditionnelles Et permet donc à un instant “T”, d’observer les opérations en cours, les fichiers ouverts, l’état des registres processeurs ,la pile d'appel mais en plus de modifier le contenu des différentes variables en mémoire, le contenu des zones mémoire, le code source en assembleur et bien d'autres options...
  • Passant maintenant aux modèles de qualité ou comme on les appelle encore “les bonnes pratiques de développement” qui sont un ensemble de règles bien définies à respecter. Qui on comme finalité de prendre en compte les contraintes du client tout en répondant aux exigences de qualité de développement.Ces modèles permettent d’encadrer les méthodes d’analyses statique et dynamique.parmi les plus connue modèles de qualité je peux cité par exemple le fameu modèle « iso 9126 »
  • Lors de cette partie je vais présenter ma méthode personnelle pour la réalisation d’un audit technique de code.La méthode que je propose est sous forme d’une liste de démarches à mettre place et à respecter.Au début l’auditeur doit utiliser le modèle de qualité personnel (que j’ai vais définir par la suite) pour orienté et cadrer les analyses qu’il va devoir effectuer ,ces analyses seront effectué pour chaque axe du modèle afin de détecter les problèmes lié au système, l’auditeur est supposé faire une étude approfondie sur ces problèmes afin de proposer les meilleures solutions possibles . Finalement il doit rédiger un rapport avec l’ensemble des problèmes identifier et les solutions proposé.
  • La première étape des démarches étai l’utilisation du modèle de qualité que j’ai définie, ce modèle est organisé en 3 axesLe premier axe est La modulabilité qui a comme exigences de disposer d’un système ouvertavec une architecture logicielle bien conçu, un code facilement évolutif et modulable.Dans le but de facilement suivre les évolutions de l’application sans trop de changement dans l’architecture, le code doit aussi permettre facilement d’ajouter de nouveaux modules, le système doit pouvoir communiquer avec d’autres systèmes externes, pour cela le code doit utiliser des technologies normalisé afin qu’il est puisse s’interfacer avec d’autres systèmes.L’axe de modulabilité se base principalement sur des métriques comme le nombre de classes….L’axe de capacité requis que le logicielle est des temps de réponses correctes sur les différents supports utilisé(que cela soit des connexion WEB ,ou des requete SQL, ou encore une communication entre composant ( corba ou ejb),l’axe de capacité requis aussiun logicielle stable qui ne plante pas à chaque problème rencontré, et arrive à tourner en a un mode dégradé en cas de problèmes graves et finalement un logiciel avec un niveau de sécurité acceptable.Le dernier axe est La qualité , ila pour but de disposer d’un code bien structuré et simple à comprendre afin de pouvoir y effectuer de la maintenance applicative sans trop de difficulté.
  • Le 2eme point de la méthodologie étai l’ensemble des analyses a effectué.Ces analyses sont organisé en deux phases qui sont appliquées pour chacune des axes du modèle définis:Une phase in vivo qui correspond a l’analyse dynamique etune phase ex vivo qui correspond a l’analyse statique Les problèmes détectés lors de ces deux phases feront l’objet d’une étude approfondie par l’auditeur qui est supposé proposer les meilleures solutions possibles à ces problèmes.
  • Donc passons maintenant a ce que j’ai mis en place a l’entreprise , Donc a ALTIj’ai pu réaliser un petit audit technique de code, pour cela j’ai du installer et configurer au début une plateforme d’intégration continue basé sur Hudson et sonar pour les métrique.J’ai aussi installé les plug-ins Findbugs , Cobertura et CheckStyle pour sonar et Eclipse. Puis j’ai utilisé ma méthodologie personnel que j’ai décrite tout a l’heure pour étudier et analyser l’application TECK.Apres cette analyse j’ai pu réaliser un mini rapport ou j’ai répertorier l’ensembles des problèmes détecter et les éventuel solution pour les corriger.Par exemples dans l’application teck j’ai identifier des difficulté de maintenance de l’application mais plus spécifiquement la couche présentation vue qu’elle disposer d’un code avec beaucoup d’imbrication cyclique ou encore du code redondant. comme solution j’ai proposer de créer des classes utilitaire pour éviter les copier coller et de refactoré le code source.Il avait aussi un problème pour l’évolution de l’application vue la non séparation de la couches présentation et traitements.Mon but principale derrière cette audit étai pour des fins d’optimisation, vue que cela fessai partie de mes missions.J’ai donc identifier quelques problème majeurs, tel que l’application effectué plusieurs appels entre le client et le serveur la ou elle pouvait en effectué qu’un seul(cas ajout de plusieurs lignes de demande d’achats)ou encore j’ai remarqué que les fichiers de mapping « dozer » étai mal écrit et donc on récupéré des donnée supplémentaire sans aucun intérêt fonctionnelle.la ou on pouvais juste récupérer juste les information dont l’application avait besoin.Mais ce n’etait pas tout l’application perdais en performance aussi vue qu’elle créé beaucoup d’objet inutile(donc elle occupé de la place en plus en mémoire et perdez du temps lors de leurs création)Ou encore elle perdais du temps a faire des conversions inutile.L’application faisait trop appels a l’introspection même a des endroits ou l’on pouvais éviter cela…..Ce qui ralentissais d’avantage l’application.Niveau securté l’application ne disposai pas de système pour valider et controler les donnée entré.l’une de mes missions etai la creation de PDI pour protocole de document incomplet ou le but etai de verifier les champs obligatoire a la saisie , la validiter des donnée ainsi de suite.Check Style Est un outil qui dispose d’une liste de règles de codage personnalisable (environ 150 règles) afin de vérifier et améliorer la qualité du code. Check Style est capable de :Vérifier la longueur des lignes de codeVérifier la présence de la « Java Doc »Vérifier le respect des standards de nommage Améliorer l'écriture et la qualité du codeFindbugs  Est un outil qui permet d’effectuer une analyse détaillé du code Java, il permet d’identifier des anomalies avancée comme : Détection des mauvaises pratiques de codageL’identification des failles de sécurité comme : utilisation de variables instancié à NULL;Détection des problèmes pouvant causer des régressions dans les performancesProblèmes liés au ThreadCoberturaEst un outil qui permet principalement de mesurer la couverture du code par les tests unitaires.Mais aussi d’analyser les lignes et les branches, ainsi que la complexité McCabeGrace a une intégration avec Sonar, il est tout à fait possible d'obtenir des mesures au niveau du projet, des packages, des classes ou des méthodes.SonarPermet de fournir une analyse complète de la qualité du code grâce à divers métriques. Sonar est capable de gérer différents langages (JAVA, C#, FLEX,…)Sonar est un projet tout en un, grâce à son système de plug-in, sonar permet d’intégrer et tirer profit de la puissance d’outils comme : Check Style, FindBugs, Cobertura…
  • Nous avons vue lors de cette présentation ce qu’est l’audit technique de code ,les différents axes qu’il peut traiter et les différents acteurs qui sont impliqué, nous avons compris qu’il est impérative de passer par une conduite de changement vis-à-vis ces derniers.Nous avons aussi pris connaissance de l’ensemble des étapes a suivre pour la mise en place d’un tel audit, et nous avons compris qu’un tel audit se base sur les deux méthodes d’analyses (analyse statique et dynamique ) et qu’il est impérativement indispensables de disposer d’un modèle de qualité pour orienté ces analyses.finalement j’ai présenter la solution mise en place a l’entreprise
  • Audit technique de code

    1. 1. MémoireAudit Technique de codeAnalyses et suivis de qualité<br />Présenté par : Mr TAZI Mehdi <br />1<br />
    2. 2. Plan<br />2<br />Quand l’effectuer ?<br />Quel sont ses axes ?<br />Pourquoi faire ? <br />C’est Quoi ? <br />Qui l’effectue et qui est concernés?<br />Méthode de mise en place personnelle<br />Conclusion<br />Méthodes d’analyses et modèles de qualité<br />Audit technique de code<br />Introduction<br />Mise en œuvre de la solution<br />
    3. 3. Introduction<br />Stage effectué au sien d’ALTI<br />ALTI : SSII 1200 collaborateurs<br />Intégration de l’équipe de développement du projet TECK<br />TECK : gérer les processus métier de L’ONF<br />Missions Principales : <br />La Correction des anomalies<br />Participation aux développements et aux évolutions<br />L’optimisation et le « reFactoring » du code.<br />Constatations : <br />Lenteur dans l’application en générale<br />Difficulté de compréhension et de maintenance du code<br />Audit Technique de code : <br />Pas une tache facile<br />Pas de standard a suivre<br />3<br />
    4. 4. Audit technique de code<br /><ul><li>Définition de l’audit Technique en générale </li></ul>Identifier les points forts et faibles<br />du système<br />Outil de contrôle et de conseil<br />But<br />Obtenir des <br />solutions et recommandations<br />Corriger et Améliorer les anomalies <br />4<br />Point sur l’existant<br />
    5. 5. Audit technique de code<br />5<br /><ul><li>Types d’audits techniques </li></li></ul><li>Audit technique de code<br /><ul><li>C’est quoi l’audit de code ?</li></ul>Analyse et vérification <br />du code<br />Optimiser le développement<br /> Réduire les cout et les délais<br />6<br />But<br />Se base<br />Modèles de qualité <br />Adaptée<br />Demandes des clients <br />
    6. 6. Audit technique de code<br /><ul><li>L’audit de code, pourquoi faire ?
    7. 7. Surveiller la qualité du code des projets </li></ul>susceptibles d’évoluer dans le temps.<br /><ul><li>Les grands projets coûtent des millions</li></ul> d’euros<br />7<br />Améliorer la qualité de l’application<br />Identifier et anticiper les problèmes de performance et de sécurité<br />Optimiser les développements et la maintenance du code applicatif<br />Optimiser la maintenance corrective et évolutive<br />Augmenter les performances des applications<br />Augmenter la sécurité des applications<br />L’audit technique de code est reconnu comme un outil incomparable<br />
    8. 8. Audit technique de code<br />8<br />Architecture logicielle<br />Respect des normes et des Frameworks utilisés<br />Robustesse / <br />Fiabilité<br />/<br />Scalabilité<br />Documentation technique<br />Evolutivité<br />Maintenance<br />Performances<br />Sécurité<br /><ul><li>Les Différents axes traités par l’audit de code</li></li></ul><li>Audit technique de code<br />9<br />Voir plus claire<br />Suvi de code<br /><ul><li>Nouveau projet ou un projet pour la TMA
    9. 9. Mise en place d’une PIC et de suivi de qualité
    10. 10. Suivre les évolutions à chaque intervention sur le code et à chaque livraison
    11. 11. Utile dans le cadre de la sous-traitance
    12. 12. Boite noire
    13. 13. Pas d’indicateurs
    14. 14. Avoir des mesures plus claires
    15. 15. Audit de code approfondi
    16. 16. Identifier le maximum de problèmes
    17. 17. Proposer des solutions
    18. 18. Demande du temps d’elaboration
    19. 19. Quand l’effectuer ? </li></ul>2<br />1<br />
    20. 20. Audit technique de code<br /><ul><li>Qui l’effectue ?
    21. 21. Une société spécialisée en ingénierie et service informatique (SSII)
    22. 22. Un Freelance</li></ul>10<br />Compétences <br />Techniques <br />avancées<br />Gestionnaire<br />Architecture <br />de Haut Niveau<br />Organisateur<br />
    23. 23. Audit technique de code<br /><ul><li>Qui est concerné ?
    24. 24. Acteurs principaux : Les développeurs
    25. 25. Acteurs secondaires : Les décideurs (Directeurs, Chefs de projet, Managers)</li></ul>11<br />Architecture<br />Haut Niveau<br />Organisateur<br />
    26. 26. Audit technique de code<br /><ul><li>Conduite de changements</li></ul>12<br /><ul><li>Choix des règles
    27. 27. Fournir les indicateurs pour une
    28. 28. auto correction
    29. 29. implication au travail
    30. 30. Faciliter l’organisation et le travail
    31. 31. Eviter les régressions
    32. 32. Rapidité de corrections</li></li></ul><li>Méthodes d’analyses et modèles de qualité<br /><ul><li>En quoi consiste l’audit de code ?</li></ul>13<br />Analyse Dynamique<br /><ul><li>Audit de code est un ensemble d’analyses
    33. 33. Etude de la syntaxe du code : la manière dont le code est structuré
    34. 34. Etude de l’exécution du code : comment le code est exécuté ?</li></ul>Analyse Statique<br /><ul><li>Ces analyses sont effectuées selon 2 méthodes : </li></li></ul><li>Méthodes d’analyses et modèles de qualité<br />14<br />Erreurs de programmation<br />Erreurs de conception<br />Failles de sécurité<br /><ul><li>L’analyse statique</li></ul>Bugs potentiels<br />Code suspect<br />Obtenir des informations sur le comportement du programme sans « Exécution » ni « Compilation » du code source<br />Sémantique du code source<br />Analyse et teste de syntaxe<br />Pratique risqué<br />Règles d’écritureet de nommage<br />L’analyse statique s’effectue <br />Détecter<br />Identifier<br />vérifier<br />
    35. 35. Méthodes d’analyses et modèles de qualité<br />15<br />Fuites de mémoire et des problèmes de performances<br />Variables initialiser mais non utilisées<br /><ul><li>L’analyse statique</li></ul>Failles de sécurité ( Buffer overflow)<br />Redondance du code ( code copié collé )<br /><ul><li>Objectif :
    36. 36. Evaluer la qualité , les performances et la sécurité du code
    37. 37. Déterminer la facilité ou la difficulté de la maintenance du code
    38. 38. Avant toute étude du comportement du code ( A. Dynamique)</li></ul>Variables déclarées 2 fois<br />Code mort ( zone de code non utilisé )<br />Méthodes privées jamais appelées<br /><ul><li>Exemples : </li></ul>Règles de nommage<br />
    39. 39. Méthodes d’analyses et modèles de qualité<br />16<br />Ouverture d’un fichier inexistant<br />Sécurité du système : Droit d’accès en écriture<br />Pointeur sur une adresse mémoire non alloué<br /><ul><li>L’analyse dynamique</li></ul>Débogage<br />Profiling<br />Analyse Dynamique<br /><ul><li>Simuler l’exécution du code sur un vrai processeur ou un processeur virtuel
    40. 40. Révéler des erreurs de codage comportementale non visibles par une analyse statique </li></ul>détecter<br />
    41. 41. Méthodes d’analyses et modèles de qualité<br />17<br />Fréquences des appels de méthodes<br />Durée des appels de méthodes<br /><ul><li>L’analyse dynamique
    42. 42. Le Profiling: Technique d’analyse de performances
    43. 43. Le Débogage: Exécuter le code source pas a pas.
    44. 44. Point d’ arret conditionnelles</li></ul>Parties<br />critiques<br />du code<br />Les opérations en cours <br />Contenu des variables en mémoire <br />Contenu des zones mémoire <br />Etats des registres <br />Fichiers ouverts <br />Pile d’appels <br />Code source en assembleur <br />Observer et modifier <br />
    45. 45. Méthodes d’analyses et modèles de qualité<br /><ul><li>Modèles de qualité</li></ul>18<br /><ul><li>Les bonnes pratiques de développement
    46. 46. Ensemble de règles bien définies à respecter
    47. 47. Prendre en compte les contraintes du client
    48. 48. Répondre aux exigences de qualité de développement</li></ul>Méthodes d’analyses<br />Modèle de qualité<br />Exemples : iso 9126<br />
    49. 49. Méthodes d’analyses et modèles de qualité<br />19<br />Utilisation du modèle de qualité<br />Analyses selon les axes<br />Rédaction d’un rapport<br /><ul><li>Méthode de mise en place personnelle
    50. 50. Une liste de démarches
    51. 51. A respecter et mettre en place</li></ul>Détection des problèmes<br />Proposition des solutions<br />Etude approfondie<br />
    52. 52. Méthodes d’analyses et modèles de qualité<br />20<br /><ul><li>Méthode de mise en place personnelle
    53. 53. Code bien structuré
    54. 54. Facile à comprendre
    55. 55. Maintenance applicatif
    56. 56. Temps de réponses correcte
    57. 57. [Internet,DB,Component]
    58. 58. Stabilité
    59. 59. Sécurité
    60. 60. Système ouvert
    61. 61. Architecture logicielle
    62. 62. Code Evolutif
    63. 63. Code Modulable</li></ul>Les Trois Axes du modèle :<br />La capacité<br />La qualité<br />La modulabilité<br /><ul><li>Redondance du code
    64. 64. Couverture du code par les testes unitaires
    65. 65. Variables lue avant d’être initialiser
    66. 66. Zone de code non utilisé
    67. 67. Classes et méthodes non documenté
    68. 68. Testes de charges
    69. 69. Testes de performances
    70. 70. Testes de stresse
    71. 71. Nombre classes ,attributs méthodes
    72. 72. Nombre d’agrégation , dépendances, généralisation
    73. 73. Couplage entre les objets
    74. 74. Profondeurs de l’arbre d’héritage</li></li></ul><li>Méthodes d’analyses et modèles de qualité<br /><ul><li>Méthode de mise en place personnel</li></ul>21<br />Qualité<br />Capacité<br />Modulabilité<br />Ex Vivo<br />In Vivo<br />Détection des problèmes<br />
    75. 75. Mise en œuvre de la solution<br /><ul><li>Mise en œuvre de la solution</li></ul>22<br /><ul><li>Installation des outils
    76. 76. FindBugs
    77. 77. Cobertura
    78. 78. CheckStyle
    79. 79. Installation de la PIC
    80. 80. Hudson
    81. 81. Sonar
    82. 82. Analyse et études
    83. 83. Méthodologie personnel
    84. 84. Mise en place d’un rapport
    85. 85. Exemples de problèmes identifié
    86. 86. Difficulté de maintenance de la couche présentation :
    87. 87. Imbrication cyclique des classes
    88. 88. Code redondant ( trop de copié collé )
    89. 89. Refactoring du code,creation de classe utilitaire
    90. 90. Difficulté d’évolution de l’application:
    91. 91. Non séparation des couches « présentation » et « traitements »
    92. 92. Problèmes de performances
    93. 93. De nombreux appels entre le client et le serveur
    94. 94. Fichier de mapping mal écrit
    95. 95. Trop d’objets créé
    96. 96. Trop de conversion entre les objets
    97. 97. Introspection inutile
    98. 98. Problèmes de sécurité fonctionnelle:
    99. 99. PDI : protocole document incomplet</li></li></ul><li>Méthodes d’analyses et modèles de qualité<br /><ul><li>Conclusion</li></ul>23<br /><ul><li>Audit technique de code
    100. 100. Axes traité
    101. 101. Acteurs impliqué
    102. 102. Conduite de changement
    103. 103. Méthodologie
    104. 104. Etapes a suivre
    105. 105. Méthodes d’analyses
    106. 106. Modèle de qualité
    107. 107. Mise en œuvre
    108. 108. Solution</li></li></ul><li>Merci pour votre attention<br />24<br />

    ×