{"id":218,"date":"2012-09-11T11:01:41","date_gmt":"2012-09-11T10:01:41","guid":{"rendered":"http:\/\/dev.qualilogy.com\/fr\/?p=218"},"modified":"2013-01-05T11:02:09","modified_gmt":"2013-01-05T10:02:09","slug":"complexite-et-effort-de-test","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/complexite-et-effort-de-test\/","title":{"rendered":"Complexit\u00e9 et effort de test"},"content":{"rendered":"<p>Dans le <a title=\"Taille d'une application\" href=\"http:\/\/qualilogy.com\/fr\/taille-dune-application\" target=\"_blank\">post pr\u00e9c\u00e9dent<\/a>, je posais la question \u2018Qu\u2019est ce qu\u2019une grosse application ?\u2019 et je proposais deux tables de mesures, bas\u00e9es sur le nombre de lignes de codes (LOC) ou le nombre d\u2019objets afin de cat\u00e9goriser les applications en \u2018simple\u2019, \u2018moyenne\u2019, \u2018grosse\u2019 et \u2018tr\u00e8s grosse\u2019.<\/p>\n<p>Evidemment, comme je m\u2019y attendais, la discussion sur les forums traitant d\u2019analyse de code ou de m\u00e9triques software s\u2019est imm\u00e9diatement orient\u00e9e sur les points de fonction, sur la d\u00e9finition de ce qu\u2019est une application (unit\u00e9 de code ou unit\u00e9 organisationnelle) ou sur le type de mesure utilis\u00e9e par chacun afin d\u2019estimer la taille d\u2019une application. Les nombres que j\u2019ai avanc\u00e9s n\u2019ont pas pr\u00eat\u00e9 \u00e0 discussion.<\/p>\n<p>Cette semaine encore, un autre \u2018quizz\u2019 du m\u00eame type : \u2018Qu\u2019est ce qu\u2019une application complexe ?\u2019 et surtout \u2018Est-il possible de pr\u00e9voir l\u2019effort de test en fonction de la complexit\u00e9 d\u2019une application ?\u2019.<\/p>\n<p><!--more--><\/p>\n<p>Nous savons tous que la Complexit\u00e9 Cyclomatique de McCabe (CC) est la principale m\u00e9trique utilis\u00e9e pour mesurer la complexit\u00e9, et qu\u2019elle est commun\u00e9ment admise par tous, sans contestation ou pol\u00e9mique comme ce peut \u00eatre le cas de la LOC pour la mesure de la taille. Rappelons le principe de cette m\u00e9trique : mesurer le nombre de chemins ind\u00e9pendants dans l&rsquo;algorithme du code source.<\/p>\n<p>Prenons un exemple concret. Soit la r\u00e8gle de gestion suivante : \u2018si commande &gt; 50, ristourne = 1%\u2019. En pseudo-code, cela se traduira de la mani\u00e8re suivante :<\/p>\n<pre>IF commande &gt; 50\r\n  THEN ristourne = 1%\r\nELSE\r\n  Ristourne = 0%\r\nENDIF<\/pre>\n<p>L\u2019algorithme pour cette r\u00e8gle de gestion comportera donc deux chemins distincts correspondants aux deux parties de la condition : la commande donne droit \u00e0 une ristourne ou non. Ces deux chemins \u00e9quivalent \u00e0 deux points de Complexit\u00e9 Cyclomatique.<\/p>\n<p>Compliquons maintenant nous cette r\u00e8gle, ou plut\u00f4t, ajoutons de nouvelles r\u00e8gles : \u2018si commande &gt; 500, ristourne = 10%\u2019, \u2018si commande &gt; 300, ristourne = 5%\u2019, \u2018si commande &gt; 200, ristourne = 2%\u2019.<\/p>\n<p>Le pseudo-code correspondant devient d\u00e9s lors :<\/p>\n<pre> IF commande &gt; 500\r\n   THEN ristourne = 10%\r\n   ELSEIF commande &gt; 300\r\n     THEN ristourne = 5%\r\n     ELSEIF commande &gt; 200\r\n       THEN ristourne = 2%\r\n       ELSEIF commande &gt; 50\r\n         THEN ristourne = 1%\r\n         ELSE Ristourne = 0%\r\n       ENDIF\r\n     ENDIF\r\n   ENDIF\r\n ENDIF<\/pre>\n<p>Remarquez que j\u2019ai (volontairement) choisi la mani\u00e8re la plus complexe et la moins correcte de &lsquo;pesudo-coder&rsquo; ces diff\u00e9rentes r\u00e8gles, avec plusieurs IF imbriqu\u00e9s. Mais ce n&rsquo;est pas l&rsquo;objet de ce post.<\/p>\n<p>Dans cet exemple, nous avons quatre conditions plus un cas dans lequel aucune condition ne sera remplie. Ou pour le dire autrement, nous avons ajout\u00e9 trois r\u00e8gles suppl\u00e9mentaires au cas pr\u00e9c\u00e9dent et notre Complexit\u00e9 Cyclomatique sera donc plus \u00e9lev\u00e9e.<br \/>\nTous les outils d\u2019analyse de code ne calculent pas la Complexit\u00e9 Cyclomatique de la m\u00eame mani\u00e8re, donc le r\u00e9sultat pourra varier (de plus ou moins un) selon celui que vous utiliserez, mais l\u00e0 encore, ce n&rsquo;est pas l&rsquo;objet de ce post. Disons simplement que nous avons l\u00e0 une CC \u00e9gale \u00e0 5, correspondant \u00e0 cina chemins distincts dans l\u2019algorithme, \u00e0 cinq valeurs distinctes pour les objets \u2018ristourne\u2019 ou \u2018commande\u2019.<\/p>\n<p>Diriez-vous que, dans une phase de QA, il faut tester ces diff\u00e9rentes valeurs ?<\/p>\n<p>Si votre r\u00e9ponse est positive, alors cela signifie que la Complexit\u00e9 Cyclomatique constitue un bon indicateur du nombre de cas de tests. Evidemment, si vous avez une application avec 10 000 points de CC, cela ne veut pas dire qu\u2019il vous faille tester 10 000 cas diff\u00e9rents, ni m\u00eame que vous aurez une application ne pr\u00e9sentant aucun d\u00e9faut si vous testez tous les cas possibles. Mais au moins, vous pouvez estimer plus pr\u00e9cis\u00e9ment l\u2019effort de test, selon que la CC sera de 2 000 points, 20 000 ou 100 000 points.<\/p>\n<p>La question de notre \u2018quizz\u2019 pr\u00e9c\u00e9dent \u00e9tait : \u2018Qu\u2019est-ce qu\u2019une grosse application ?\u2019. Cette semaine, la question sera double :<\/p>\n<ul>\n<li>Qu\u2019est ce qu\u2019une application complexe ?<\/li>\n<li>Quel niveau de QA pr\u00e9coniser en fonction de quel niveau de complexit\u00e9 ?<\/li>\n<\/ul>\n<p>Voici le tableau que je vous propose :<\/p>\n<h4 style=\"text-align: center\"><em><span style=\"text-decoration: underline\"><strong>Complexit\u00e9 de l\u2019application en points de CC<\/strong><\/span><\/em><\/h4>\n<table width=\"643\" border=\"1\" cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr>\n<td valign=\"top\" width=\"100\">\n<p align=\"left\"><strong>Complexit\u00e9<\/strong><\/p>\n<\/td>\n<td valign=\"top\" width=\"127\">\n<p style=\"text-align: center\"><strong>Basse<\/strong><\/p>\n<\/td>\n<td valign=\"top\" width=\"127\">\n<p style=\"text-align: center\"><strong>Moyenne<\/strong><\/p>\n<\/td>\n<td valign=\"top\" width=\"127\">\n<p style=\"text-align: center\"><strong>Elev\u00e9e<\/strong><\/p>\n<\/td>\n<td valign=\"top\" width=\"154\">\n<p style=\"text-align: center\"><strong>Tr\u00e8s \u00e9lev\u00e9e<\/strong><\/p>\n<\/td>\n<\/tr>\n<tr>\n<td valign=\"top\" width=\"127\"><strong>Points de CC<\/strong><\/td>\n<td valign=\"top\" width=\"127\">\n<p align=\"center\">6 000<\/p>\n<\/td>\n<td valign=\"top\" width=\"127\">\n<p align=\"center\">16 000<\/p>\n<\/td>\n<td valign=\"top\" width=\"127\">\n<p align=\"center\">50 000<\/p>\n<\/td>\n<td valign=\"top\" width=\"127\">\n<p align=\"center\">&gt; 50 000<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3><strong>Application peu complexe<\/strong><\/h3>\n<p>Avec moins de 6 000 &lsquo;chemins&rsquo; dans l&rsquo;application, des tests unitaires au niveau de l\u2019\u00e9quipe de projet devraient suffire pour v\u00e9rifier la plupart des cas. Cela suppose bien \u00e9videmment une bonne connaissance fonctionnelle de l\u2019application.<\/p>\n<p>G\u00e9n\u00e9ralement, les sp\u00e9cifications sont tr\u00e8s peu formalis\u00e9es, les d\u00e9veloppeurs sont en contact direct avec les utilisateurs ou leur repr\u00e9sentant jouant un r\u00f4le de MOA (Ma\u00eetrise d\u2019ouvrage, interface entre les utilisateurs et l\u2019\u00e9quipe projet).<\/p>\n<h3><strong>Application moyennement complexe<\/strong><\/h3>\n<p>Entre 6 000  et 16 000 points de CC, les tests unitaires sont n\u00e9cessaires, comme pr\u00e9c\u00e9demment et deviennent suffisamment nombreux pour que l\u2019\u00e9quipe de projet se dote d\u2019un outillage permettant d\u2019automatiser ceux-ci. La taille du code et surtout le nombre de cas de test cro\u00eet de mani\u00e8re importante.<\/p>\n<p>La connaissance des sp\u00e9cifications fonctionnelles est r\u00e9partie sur divers membres de l\u2019\u00e9quipe de projet : on commence \u00e0 voir appara\u00eetre une sp\u00e9cialisation des d\u00e9veloppeurs sur certaines parties du code ou diff\u00e9rents modules fonctionnels. Une \u00e9tape sp\u00e9cifique d\u2019int\u00e9gration est n\u00e9cessaire, afin de v\u00e9rifier que l\u2019assemblage des diff\u00e9rents composants en cha\u00eenes de traitements fonctionnels correspond aux demandes m\u00e9tier.<\/p>\n<h3><strong>Application complexe<\/strong><\/h3>\n<p><strong><\/strong>Les seuils peuvent varier entre 16 000 et 20 000 points de CC pour la limite basse, et 50 000 et 60 000 points de CC pour la limite haute, notamment en fonction des technologies ou de l\u2019architecture de l\u2019application ou de la fr\u00e9quence d\u2019\u00e9volution du code. Il n\u2019existe \u00e9videmment pas de limite pr\u00e9cise, mais plus on se rapproche d\u2019un seuil et plus la strat\u00e9gie de test correspondante devient applicable.<\/p>\n<p>Au-del\u00e0 de 16 000 points de CC (et surtout au-del\u00e0 de 20 000), l\u2019application est complexe. La taille de l\u2019\u00e9quipe projet peut devenir importante, notamment si les corrections ou \u00e9volutions sont fr\u00e9quentes.<\/p>\n<p>Outre les tests unitaires et d\u2019int\u00e9gration au niveau de l\u2019\u00e9quipe de projet, il devient indispensable d\u2019effectuer une phase sp\u00e9cifique de tests fonctionnels avec une \u00e9quipe de QA d\u00e9di\u00e9e. La formalisation des cas de tests sur la base d\u2019un document de sp\u00e9cifications fonctionnelles est de plus en plus indispensable lorsque la complexit\u00e9 se rapproche de la limite haute.<\/p>\n<h3><strong>Application tr\u00e8s complexe<\/strong><\/h3>\n<p>Au-del\u00e0 de 50 000 ou 60 000 points, l\u2019application est tr\u00e8s complexe. Il est n\u00e9cessaire de s\u2019\u00e9quiper d\u2019outils pour automatiser les tests unitaires, d\u2019int\u00e9gration ou de QA. Les sp\u00e9cifications fonctionnelles doivent imp\u00e9rativement \u00eatre r\u00e9dig\u00e9es et fig\u00e9es avant la phase de d\u00e9veloppement.<\/p>\n<p>J\u2019ai rencontr\u00e9 peu d\u2019applications au-del\u00e0 des 100 000 points de CC, m\u00eame dans le monde mainframe. Il existe peu de situations &lsquo;m\u00e9tier&rsquo; avec des r\u00e8gles de gestion aussi complexes. On les rencontre g\u00e9n\u00e9ralement dans les domaines administratifs o\u00f9 la r\u00e9glementation \u00e9volue tr\u00e8s fr\u00e9quemment : par exemple les traitements de calcul des allocations familiales, avec des r\u00e8gles nouvelles qui s\u2019ajoutent \u00e0 des r\u00e8gles anciennes rarement supprim\u00e9es.<\/p>\n<p>La plupart du temps, de tels monstres supposent une d\u00e9rive du management qui a laiss\u00e9 l\u2019application devenir de plus en plus complexe. On les rencontre dans des secteurs correspondant \u00e0 des march\u00e9s qui sont pass\u00e9s rapidement d\u2019une croissance tr\u00e8s forte, justifiant des \u00e9volutions applicatives fr\u00e9quentes et sans aucun souci de la dette technique, \u00e0 une phase de stabilisation voire de d\u00e9clin des parts de march\u00e9 entra\u00eenant une r\u00e9duction des budgets informatiques et rendant impossible tout refactoring pour diminuer cette dette technique. Les int\u00e9r\u00eats de celle-ci resteront \u00e9lev\u00e9s encore longtemps.<\/p>\n<p>Et vous, pensez-vous que la mesure de la complexit\u00e9 soit un indicateur de l&rsquo;effort de QA ?<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Dans le post pr\u00e9c\u00e9dent, je posais la question \u2018Qu\u2019est ce qu\u2019une grosse application ?\u2019 et je proposais deux tables de mesures, bas\u00e9es sur le nombre de lignes de codes (LOC) ou le nombre d\u2019objets afin de cat\u00e9goriser les applications en \u2018simple\u2019, \u2018moyenne\u2019, \u2018grosse\u2019 et \u2018tr\u00e8s grosse\u2019. Evidemment, comme je m\u2019y attendais, la discussion sur les [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[],"class_list":["post-218","post","type-post","status-publish","format-standard","hentry","category-qa"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/218"}],"collection":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/comments?post=218"}],"version-history":[{"count":1,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/218\/revisions"}],"predecessor-version":[{"id":219,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/218\/revisions\/219"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=218"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=218"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=218"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}