![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/01\/Qual8crit2.jpg\" "\\"Qual8crit2\\"")
<\/a>Nombre de technologies analys\u00e9es<\/span><\/p>\nNe choisissez pas un outil uniquement parce qu\u2019il sait aussi analyser du PL1 ou du Powerbuilder si ces technologies repr\u00e9sentent moins de 10% de votre syst\u00e8me d\u2019information.<\/p>\n
Vous ne d\u00e9veloppez pas de nouvelles applications avec ces langages, vous attendez que les applications existantes meurent ou soient migr\u00e9es. Et vous le savez bien, l\u2019investissement d\u2019un \u00e9diteur logiciel sur une technologie est proportionnel aux ventes : un analyseur PL1 n\u2019offrira jamais le m\u00eame niveau de fonctionnalit\u00e9s qu\u2019un analyseur J2EE. Ne les mettez pas sur le m\u00eame plan.<\/p>\n
Nombre de m\u00e9triques<\/span><\/h3>\nLa plupart des cas d\u2019utilisation d\u2019un outil d\u2019analyse de code \u2013 Continuous Integration \/ Improvement, Quality Gate, Gestion de l\u2019outsourcing \u2013 s\u2019appuient sur ensemble r\u00e9duit de 10 \u00e1 20 m\u00e9triques. Identifiez les m\u00e9triques critiques pour les Use Cases que vous souhaitez impl\u00e9menter. Identifiez ensuite les m\u00e9triques qui vous paraissent int\u00e9ressantes ou utiles. Le reste est du \u2018nice to have\u2019.<\/p>\n
Possibilit\u00e9 de cr\u00e9er de nouvelles m\u00e9triques<\/span><\/h3>\nPourquoi 90% des utilisateurs d\u2019un outil d\u2019analyse de code sont satisfaits des m\u00e9triques fournies ? Parce qu\u2019elles correspondent \u00e0 des standards du march\u00e9. Evitez de jouer \u00e0 l\u2019apprenti sorcier en cr\u00e9ant vos propres standards : cela vient avec un co\u00fbt, de d\u00e9veloppement, de maintenance, d\u2019impl\u00e9mentation et de support \u00e0 chaque upgrade de l\u2019outil.<\/p>\n
Liens entre composants<\/span><\/h3>\nSur les 3 technologies le plus souvent rencontr\u00e9es \u2013 J2EE, Cobol, SAP \u2013 seule la premi\u00e8re est multi-tiers. Si vous utilisez des frameworks J2EE, des m\u00e9triques bas\u00e9es sur les liens entre composants peuvent s\u2019av\u00e9rer utiles. Retenez n\u00e9anmoins qu\u2019elles repr\u00e9sentent une faible proportion du total des r\u00e8gles, et que leur utilisation pr\u00e9sente un co\u00fbt, notamment dans la validation des false-positives.<\/p>\n
Voyons maintenant 3 crit\u00e8res que j’estime r\u00e9ellement importants.<\/p>\n
Mod\u00e8les Qualit\u00e9 multiples<\/span><\/h3>\nL\u2019ensemble des m\u00e9triques et leur organisation sur diff\u00e9rents facteurs constituent votre mod\u00e8le Qualit\u00e9, la grille de mesures selon laquelle vous allez \u00e9valuez la qualit\u00e9 de vos applications. Plus vous disposez de souplesse dans la constitution de diff\u00e9rents mod\u00e8les, plus fine sera votre \u00e9valuation.<\/p>\n
A partir de combien de lignes un programme Cobol est-il tr\u00e8s volumineux ? A partir de combien points de complexit\u00e9 (CC) est-il tr\u00e8s complexe ? Les programmes Batch sont plus lourds que les programmes TP (transactionnels) et il est souhaitable de pouvoir affecter des seuils diff\u00e9rents sur ces m\u00e9triques. Dans le cas contraire, une \u00e9quipe de projet qui doit effectuer la maintenance d\u2019une application Batch sera p\u00e9nalis\u00e9e par rapport \u00e0 une \u00e9quipe qui g\u00e8re une application TP.<\/p>\n
Autres exemples :<\/p>\n
\n- Une base de donn\u00e9es cro\u00eet avec l\u2019accumulation de \u2018data\u2019 et au fil du temps, certaines \u2018bad practices\u2019 de programmation SQL vont commencer \u00e0 produire leurs effets, n\u00e9fastes pour la performance des applications. N\u2019attendez pas d\u2019\u00eatre dans le rouge avec les seuils par d\u00e9faut : pouvoir hausser le niveau de criticit\u00e9 autorise une gestion pro-active des risques de non-performance.<\/li>\n
- Vous savez combien co\u00fbte un projet d\u2019upgrade de versions SAP ? Vous savez le nombre de jours n\u00e9cessaires \u00e0 identifier les composants qui cesseront de fonctionner parce qu\u2019ils utilisent des syntaxes non support\u00e9es par la nouvelle version ou parce qu\u2019ils acc\u00e8dent au noyau SAP ? Ou bien vous avez une application C++ destin\u00e9e \u00e0 piloter des caisses enregistreuses de diff\u00e9rentes marques avec des OS distincts. Dans de tels cas, la portabilit\u00e9 du code devient le facteur le plus critique de votre mod\u00e8le Qualit\u00e9.<\/li>\n<\/ul>\n
Il n\u2019existe pas de Quality Model unique : autant vouloir mesurer des pommes et des patates. Pouvoir d\u00e9finir et choisir un mod\u00e8le qualit\u00e9 adapt\u00e9 \u00e0 une application donn\u00e9e est un crit\u00e8re plus important que ceux list\u00e9s pr\u00e9c\u00e9demment.<\/p>\n
Personnalisation du tableau de bord<\/span><\/h3>\nLes r\u00e9sultats des m\u00e9triques calcul\u00e9es sur le code source de vos applications appara\u00eet dans un \u2018dashboard\u2019 ou tableau de bord du pilotage de la Qualit\u00e9. La capacit\u00e9 \u00e0 personnaliser ce dashboard en fonction des use cases, des technologies ou m\u00eame d\u2019une simple application est un facteur de succ\u00e8s de votre projet Qualit\u00e9.<\/p>\n
Imaginons qu\u2019on vous demande d\u2019effectuer un audit d\u2019une application critique et d\u2019en pr\u00e9senter les r\u00e9sultats aux architectes et \u00e0 l’\u00e9quipe de projet. Au dernier moment, avant d\u2019entrer dans la salle, on vous annonce que le directeur informatique sera pr\u00e9sent. Celui-ci arrive pour se plonger imm\u00e9diatement dans la lecture de ses mails sur son Blackberry. Que faites-vous pour l\u2019int\u00e9resser \u00e0 votre pr\u00e9sentation ?<\/p>\n
Simple. Montrez lui combien lui co\u00fbte cette application.<\/p>\n
Un architecte Java ou un responsable Qualit\u00e9 sait ce qu\u2019est la Complexit\u00e9 Cyclomatique ou une m\u00e9trique telle que LCOM4. Je peux donc leur pr\u00e9senter un dashboard avec certaines m\u00e9triques (LOC, CC, taux de commentaires ou de code dupliqu\u00e9, \u2026), passer \u00e1 la liste des d\u00e9fauts les plus graves et conclure par un bilan qualitatif et quantitatif.<\/p>\n
Pour un directeur informatique, un responsable Etudes ou un manager Outsourcing, je vais commencer par un bilan financier. Je veux pouvoir afficher la dette technique en haut de la premi\u00e8re page du tableau de bord, descendre ensuite sur des axes fonctionnels tels que la maintenabilit\u00e9 ou la fiabilit\u00e9 de l\u2019application, puis une liste d\u2019indicateurs pr\u00e9sents dans un SLA (Accord de niveau de service) et terminer par un plan d\u2019action.<\/p>\n
Imaginez que vous puissiez construire par drag and drop n\u2019importe quel tableau de bord, avec un utilisateur \u00e1 vos c\u00f4t\u00e9s en lui disant : \u2018Tu veux \u00e7\u00e0 ?\u2019, \u2018Ce diagramme l\u00e0 en premier ?’, \u2018Quels indicateurs t\u2019int\u00e9ressent d\u2019abord ?\u2019.<\/p>\n
C\u00e0 c\u2019est un crit\u00e8re important.<\/p>\n
Int\u00e9gration avec d\u2019autres outils<\/span><\/h3>\nVous le savez d\u00e9j\u00e0, plus t\u00f4t un d\u00e9faut est identifi\u00e9, moins il est co\u00fbteux \u00e0 r\u00e9soudre. Et le plus t\u00f4t pour identifier un d\u00e9faut, c’est quand le programmeur vient de l\u2019\u00e9crire. Comme disait un responsable Etudes : \u00ab\u00a0Si j\u2019ai 30 d\u00e9veloppeurs sur une application, je ne vais pas attendre la fin de la semaine pour rep\u00e9rer leurs bugs\u00a0\u00bb. A 5 jours par semaine et par programmeur, cela fait 150 jours de d\u00e9fauts qui s\u2019accumulent.<\/p>\n
Id\u00e9alement, vous souhaitez :<\/p>\n
\n- Pouvoir g\u00e9rer les composants d\u2019une application au sein d\u2019un r\u00e9f\u00e9rentiel de gestion de version ou de configuration.<\/li>\n
- Pouvoir d\u00e9clencher un build (nouvelle version) de l\u2019application chaque fois qu\u2019un d\u00e9veloppeur cr\u00e9e une nouvelle version d\u2019un composant au sein du r\u00e9f\u00e9rentiel. De cette mani\u00e8re, vous pouvez v\u00e9rifier que la version compile correctement et d\u00e9clencher automatiquement une analyse du code source afin de rep\u00e9rer au plus t\u00f4t tout nouveau d\u00e9faut.<\/li>\n
- Disposer d\u2019alertes automatiques sur la survenance de certains d\u00e9fauts ou d\u2019un tableau de bord qui vous permette de r\u00e9viser facilement l\u2019apparition de nouveaux d\u00e9fauts et demander une correction.<\/li>\n
- Mettre \u00e1 jour automatiquement la liste des t\u00e2ches de chaque d\u00e9veloppeur avec les corrections \u00e0 effectuer.<\/li>\n<\/ul>\n
Pourquoi 90% des utilisateurs d\u2019un outil d\u2019analyse de code sont satisfaits des m\u00e9triques fournies ? Parce qu\u2019elles correspondent \u00e0 des standards du march\u00e9. Evitez de jouer \u00e0 l\u2019apprenti sorcier en cr\u00e9ant vos propres standards : cela vient avec un co\u00fbt, de d\u00e9veloppement, de maintenance, d\u2019impl\u00e9mentation et de support \u00e0 chaque upgrade de l\u2019outil.<\/p>\n
Liens entre composants<\/span><\/h3>\nSur les 3 technologies le plus souvent rencontr\u00e9es \u2013 J2EE, Cobol, SAP \u2013 seule la premi\u00e8re est multi-tiers. Si vous utilisez des frameworks J2EE, des m\u00e9triques bas\u00e9es sur les liens entre composants peuvent s\u2019av\u00e9rer utiles. Retenez n\u00e9anmoins qu\u2019elles repr\u00e9sentent une faible proportion du total des r\u00e8gles, et que leur utilisation pr\u00e9sente un co\u00fbt, notamment dans la validation des false-positives.<\/p>\n
Voyons maintenant 3 crit\u00e8res que j’estime r\u00e9ellement importants.<\/p>\n
Mod\u00e8les Qualit\u00e9 multiples<\/span><\/h3>\nL\u2019ensemble des m\u00e9triques et leur organisation sur diff\u00e9rents facteurs constituent votre mod\u00e8le Qualit\u00e9, la grille de mesures selon laquelle vous allez \u00e9valuez la qualit\u00e9 de vos applications. Plus vous disposez de souplesse dans la constitution de diff\u00e9rents mod\u00e8les, plus fine sera votre \u00e9valuation.<\/p>\n
A partir de combien de lignes un programme Cobol est-il tr\u00e8s volumineux ? A partir de combien points de complexit\u00e9 (CC) est-il tr\u00e8s complexe ? Les programmes Batch sont plus lourds que les programmes TP (transactionnels) et il est souhaitable de pouvoir affecter des seuils diff\u00e9rents sur ces m\u00e9triques. Dans le cas contraire, une \u00e9quipe de projet qui doit effectuer la maintenance d\u2019une application Batch sera p\u00e9nalis\u00e9e par rapport \u00e0 une \u00e9quipe qui g\u00e8re une application TP.<\/p>\n
Autres exemples :<\/p>\n
\n- Une base de donn\u00e9es cro\u00eet avec l\u2019accumulation de \u2018data\u2019 et au fil du temps, certaines \u2018bad practices\u2019 de programmation SQL vont commencer \u00e0 produire leurs effets, n\u00e9fastes pour la performance des applications. N\u2019attendez pas d\u2019\u00eatre dans le rouge avec les seuils par d\u00e9faut : pouvoir hausser le niveau de criticit\u00e9 autorise une gestion pro-active des risques de non-performance.<\/li>\n
- Vous savez combien co\u00fbte un projet d\u2019upgrade de versions SAP ? Vous savez le nombre de jours n\u00e9cessaires \u00e0 identifier les composants qui cesseront de fonctionner parce qu\u2019ils utilisent des syntaxes non support\u00e9es par la nouvelle version ou parce qu\u2019ils acc\u00e8dent au noyau SAP ? Ou bien vous avez une application C++ destin\u00e9e \u00e0 piloter des caisses enregistreuses de diff\u00e9rentes marques avec des OS distincts. Dans de tels cas, la portabilit\u00e9 du code devient le facteur le plus critique de votre mod\u00e8le Qualit\u00e9.<\/li>\n<\/ul>\n
Il n\u2019existe pas de Quality Model unique : autant vouloir mesurer des pommes et des patates. Pouvoir d\u00e9finir et choisir un mod\u00e8le qualit\u00e9 adapt\u00e9 \u00e0 une application donn\u00e9e est un crit\u00e8re plus important que ceux list\u00e9s pr\u00e9c\u00e9demment.<\/p>\n
Personnalisation du tableau de bord<\/span><\/h3>\nLes r\u00e9sultats des m\u00e9triques calcul\u00e9es sur le code source de vos applications appara\u00eet dans un \u2018dashboard\u2019 ou tableau de bord du pilotage de la Qualit\u00e9. La capacit\u00e9 \u00e0 personnaliser ce dashboard en fonction des use cases, des technologies ou m\u00eame d\u2019une simple application est un facteur de succ\u00e8s de votre projet Qualit\u00e9.<\/p>\n
Imaginons qu\u2019on vous demande d\u2019effectuer un audit d\u2019une application critique et d\u2019en pr\u00e9senter les r\u00e9sultats aux architectes et \u00e0 l’\u00e9quipe de projet. Au dernier moment, avant d\u2019entrer dans la salle, on vous annonce que le directeur informatique sera pr\u00e9sent. Celui-ci arrive pour se plonger imm\u00e9diatement dans la lecture de ses mails sur son Blackberry. Que faites-vous pour l\u2019int\u00e9resser \u00e0 votre pr\u00e9sentation ?<\/p>\n
Simple. Montrez lui combien lui co\u00fbte cette application.<\/p>\n
Un architecte Java ou un responsable Qualit\u00e9 sait ce qu\u2019est la Complexit\u00e9 Cyclomatique ou une m\u00e9trique telle que LCOM4. Je peux donc leur pr\u00e9senter un dashboard avec certaines m\u00e9triques (LOC, CC, taux de commentaires ou de code dupliqu\u00e9, \u2026), passer \u00e1 la liste des d\u00e9fauts les plus graves et conclure par un bilan qualitatif et quantitatif.<\/p>\n
Pour un directeur informatique, un responsable Etudes ou un manager Outsourcing, je vais commencer par un bilan financier. Je veux pouvoir afficher la dette technique en haut de la premi\u00e8re page du tableau de bord, descendre ensuite sur des axes fonctionnels tels que la maintenabilit\u00e9 ou la fiabilit\u00e9 de l\u2019application, puis une liste d\u2019indicateurs pr\u00e9sents dans un SLA (Accord de niveau de service) et terminer par un plan d\u2019action.<\/p>\n
Imaginez que vous puissiez construire par drag and drop n\u2019importe quel tableau de bord, avec un utilisateur \u00e1 vos c\u00f4t\u00e9s en lui disant : \u2018Tu veux \u00e7\u00e0 ?\u2019, \u2018Ce diagramme l\u00e0 en premier ?’, \u2018Quels indicateurs t\u2019int\u00e9ressent d\u2019abord ?\u2019.<\/p>\n
C\u00e0 c\u2019est un crit\u00e8re important.<\/p>\n
Int\u00e9gration avec d\u2019autres outils<\/span><\/h3>\nVous le savez d\u00e9j\u00e0, plus t\u00f4t un d\u00e9faut est identifi\u00e9, moins il est co\u00fbteux \u00e0 r\u00e9soudre. Et le plus t\u00f4t pour identifier un d\u00e9faut, c’est quand le programmeur vient de l\u2019\u00e9crire. Comme disait un responsable Etudes : \u00ab\u00a0Si j\u2019ai 30 d\u00e9veloppeurs sur une application, je ne vais pas attendre la fin de la semaine pour rep\u00e9rer leurs bugs\u00a0\u00bb. A 5 jours par semaine et par programmeur, cela fait 150 jours de d\u00e9fauts qui s\u2019accumulent.<\/p>\n
Id\u00e9alement, vous souhaitez :<\/p>\n
\n- Pouvoir g\u00e9rer les composants d\u2019une application au sein d\u2019un r\u00e9f\u00e9rentiel de gestion de version ou de configuration.<\/li>\n
- Pouvoir d\u00e9clencher un build (nouvelle version) de l\u2019application chaque fois qu\u2019un d\u00e9veloppeur cr\u00e9e une nouvelle version d\u2019un composant au sein du r\u00e9f\u00e9rentiel. De cette mani\u00e8re, vous pouvez v\u00e9rifier que la version compile correctement et d\u00e9clencher automatiquement une analyse du code source afin de rep\u00e9rer au plus t\u00f4t tout nouveau d\u00e9faut.<\/li>\n
- Disposer d\u2019alertes automatiques sur la survenance de certains d\u00e9fauts ou d\u2019un tableau de bord qui vous permette de r\u00e9viser facilement l\u2019apparition de nouveaux d\u00e9fauts et demander une correction.<\/li>\n
- Mettre \u00e1 jour automatiquement la liste des t\u00e2ches de chaque d\u00e9veloppeur avec les corrections \u00e0 effectuer.<\/li>\n<\/ul>\n
L\u2019ensemble des m\u00e9triques et leur organisation sur diff\u00e9rents facteurs constituent votre mod\u00e8le Qualit\u00e9, la grille de mesures selon laquelle vous allez \u00e9valuez la qualit\u00e9 de vos applications. Plus vous disposez de souplesse dans la constitution de diff\u00e9rents mod\u00e8les, plus fine sera votre \u00e9valuation.<\/p>\n
A partir de combien de lignes un programme Cobol est-il tr\u00e8s volumineux ? A partir de combien points de complexit\u00e9 (CC) est-il tr\u00e8s complexe ? Les programmes Batch sont plus lourds que les programmes TP (transactionnels) et il est souhaitable de pouvoir affecter des seuils diff\u00e9rents sur ces m\u00e9triques. Dans le cas contraire, une \u00e9quipe de projet qui doit effectuer la maintenance d\u2019une application Batch sera p\u00e9nalis\u00e9e par rapport \u00e0 une \u00e9quipe qui g\u00e8re une application TP.<\/p>\n
Autres exemples :<\/p>\n
- \n
- Une base de donn\u00e9es cro\u00eet avec l\u2019accumulation de \u2018data\u2019 et au fil du temps, certaines \u2018bad practices\u2019 de programmation SQL vont commencer \u00e0 produire leurs effets, n\u00e9fastes pour la performance des applications. N\u2019attendez pas d\u2019\u00eatre dans le rouge avec les seuils par d\u00e9faut : pouvoir hausser le niveau de criticit\u00e9 autorise une gestion pro-active des risques de non-performance.<\/li>\n
- Vous savez combien co\u00fbte un projet d\u2019upgrade de versions SAP ? Vous savez le nombre de jours n\u00e9cessaires \u00e0 identifier les composants qui cesseront de fonctionner parce qu\u2019ils utilisent des syntaxes non support\u00e9es par la nouvelle version ou parce qu\u2019ils acc\u00e8dent au noyau SAP ? Ou bien vous avez une application C++ destin\u00e9e \u00e0 piloter des caisses enregistreuses de diff\u00e9rentes marques avec des OS distincts. Dans de tels cas, la portabilit\u00e9 du code devient le facteur le plus critique de votre mod\u00e8le Qualit\u00e9.<\/li>\n<\/ul>\n
Il n\u2019existe pas de Quality Model unique : autant vouloir mesurer des pommes et des patates. Pouvoir d\u00e9finir et choisir un mod\u00e8le qualit\u00e9 adapt\u00e9 \u00e0 une application donn\u00e9e est un crit\u00e8re plus important que ceux list\u00e9s pr\u00e9c\u00e9demment.<\/p>\n
Personnalisation du tableau de bord<\/span><\/h3>\n
Les r\u00e9sultats des m\u00e9triques calcul\u00e9es sur le code source de vos applications appara\u00eet dans un \u2018dashboard\u2019 ou tableau de bord du pilotage de la Qualit\u00e9. La capacit\u00e9 \u00e0 personnaliser ce dashboard en fonction des use cases, des technologies ou m\u00eame d\u2019une simple application est un facteur de succ\u00e8s de votre projet Qualit\u00e9.<\/p>\n
Imaginons qu\u2019on vous demande d\u2019effectuer un audit d\u2019une application critique et d\u2019en pr\u00e9senter les r\u00e9sultats aux architectes et \u00e0 l’\u00e9quipe de projet. Au dernier moment, avant d\u2019entrer dans la salle, on vous annonce que le directeur informatique sera pr\u00e9sent. Celui-ci arrive pour se plonger imm\u00e9diatement dans la lecture de ses mails sur son Blackberry. Que faites-vous pour l\u2019int\u00e9resser \u00e0 votre pr\u00e9sentation ?<\/p>\n
Simple. Montrez lui combien lui co\u00fbte cette application.<\/p>\n
Un architecte Java ou un responsable Qualit\u00e9 sait ce qu\u2019est la Complexit\u00e9 Cyclomatique ou une m\u00e9trique telle que LCOM4. Je peux donc leur pr\u00e9senter un dashboard avec certaines m\u00e9triques (LOC, CC, taux de commentaires ou de code dupliqu\u00e9, \u2026), passer \u00e1 la liste des d\u00e9fauts les plus graves et conclure par un bilan qualitatif et quantitatif.<\/p>\n
Pour un directeur informatique, un responsable Etudes ou un manager Outsourcing, je vais commencer par un bilan financier. Je veux pouvoir afficher la dette technique en haut de la premi\u00e8re page du tableau de bord, descendre ensuite sur des axes fonctionnels tels que la maintenabilit\u00e9 ou la fiabilit\u00e9 de l\u2019application, puis une liste d\u2019indicateurs pr\u00e9sents dans un SLA (Accord de niveau de service) et terminer par un plan d\u2019action.<\/p>\n
Imaginez que vous puissiez construire par drag and drop n\u2019importe quel tableau de bord, avec un utilisateur \u00e1 vos c\u00f4t\u00e9s en lui disant : \u2018Tu veux \u00e7\u00e0 ?\u2019, \u2018Ce diagramme l\u00e0 en premier ?’, \u2018Quels indicateurs t\u2019int\u00e9ressent d\u2019abord ?\u2019.<\/p>\n
C\u00e0 c\u2019est un crit\u00e8re important.<\/p>\n
Int\u00e9gration avec d\u2019autres outils<\/span><\/h3>\n
Vous le savez d\u00e9j\u00e0, plus t\u00f4t un d\u00e9faut est identifi\u00e9, moins il est co\u00fbteux \u00e0 r\u00e9soudre. Et le plus t\u00f4t pour identifier un d\u00e9faut, c’est quand le programmeur vient de l\u2019\u00e9crire. Comme disait un responsable Etudes : \u00ab\u00a0Si j\u2019ai 30 d\u00e9veloppeurs sur une application, je ne vais pas attendre la fin de la semaine pour rep\u00e9rer leurs bugs\u00a0\u00bb. A 5 jours par semaine et par programmeur, cela fait 150 jours de d\u00e9fauts qui s\u2019accumulent.<\/p>\n
Id\u00e9alement, vous souhaitez :<\/p>\n
- \n
- Pouvoir g\u00e9rer les composants d\u2019une application au sein d\u2019un r\u00e9f\u00e9rentiel de gestion de version ou de configuration.<\/li>\n
- Pouvoir d\u00e9clencher un build (nouvelle version) de l\u2019application chaque fois qu\u2019un d\u00e9veloppeur cr\u00e9e une nouvelle version d\u2019un composant au sein du r\u00e9f\u00e9rentiel. De cette mani\u00e8re, vous pouvez v\u00e9rifier que la version compile correctement et d\u00e9clencher automatiquement une analyse du code source afin de rep\u00e9rer au plus t\u00f4t tout nouveau d\u00e9faut.<\/li>\n
- Disposer d\u2019alertes automatiques sur la survenance de certains d\u00e9fauts ou d\u2019un tableau de bord qui vous permette de r\u00e9viser facilement l\u2019apparition de nouveaux d\u00e9fauts et demander une correction.<\/li>\n
- Mettre \u00e1 jour automatiquement la liste des t\u00e2ches de chaque d\u00e9veloppeur avec les corrections \u00e0 effectuer.<\/li>\n<\/ul>\n