![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/10\/QualSoft2012r.jpg\" "\\"QualSoft2012r\\"")
<\/a>J’ai re\u00e7u des documents de Capers Jones, auteur bien connu et conf\u00e9rencier international, qu’il n’ai pas n\u00e9cessaire de pr\u00e9senter, mais au cas o\u00f9 : http:\/\/www.namcook.com\/aboutus.html<\/a>). Capers Jones est vice president et CTO de Namcook Analytics LLC.<\/p>\nCe mat\u00e9riel constitue une bonne synth\u00e8se de l’\u00e9tat actuel de la qualit\u00e9 du logiciel, dont je vais r\u00e9sumer les principaux points, ce qui me permettra \u00e9galement de poser quelques questions \u00e0 Capers.<\/p>\n
<\/p>\n
Introduction<\/strong><\/h3>\nEn 2012, plus de la moiti\u00e9 des projets logiciels de plus de 10 000 points de fonction (environ 1 000 000 lignes de code) sont soit annul\u00e9s, soit en retard de plus d’un an. Le tableau suivant pr\u00e9sente les r\u00e9sultats d’environ 13 000 projets class\u00e9s en six tailles diff\u00e9rentes, et les pourcentages de ceux qui sont \u00e0 l’heure, en avance, en retard ou supprim\u00e9s.<\/p>\n
Table 1: Software Project Outcomes By Size of Project <\/span><\/strong><\/em><\/p>\n\n\n<\/td>\n Early<\/strong><\/td>\nOn-Time<\/strong><\/td>\nDelayed<\/strong><\/td>\nCanceled<\/strong><\/td>\n<\/tr>\n\n1 FP<\/td>\n 14.68%<\/td>\n 83.16%<\/td>\n 1.92%<\/td>\n 0.25%<\/td>\n<\/tr>\n \n10 FP<\/td>\n 11.08%<\/td>\n 81.25%<\/td>\n 5.67%<\/td>\n 2.00%<\/td>\n<\/tr>\n \n100 FP<\/td>\n 6.06%<\/td>\n 74.77%<\/td>\n 11.83%<\/td>\n 7.33%<\/td>\n<\/tr>\n \n1 000 FP<\/td>\n 1.24%<\/td>\n 60.76%<\/td>\n 17.67%<\/td>\n 20.33%<\/td>\n<\/tr>\n \n10 000 FP<\/td>\n 0.14%<\/td>\n 28.03%<\/td>\n 23.83%<\/td>\n 48.00%<\/td>\n<\/tr>\n \n100 000 FP<\/td>\n 0.00%<\/td>\n 13.67%<\/td>\n 21.33%<\/td>\n 65.00%<\/td>\n<\/tr>\n \nAverage<\/em><\/td>\n5.53%<\/em><\/td>\n56.94%<\/em><\/td>\n13.71%<\/em><\/td>\n23.82%<\/em><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nQ: Capers, comment avez-vous r\u00e9ussi \u00e0 obtenir toutes ces donn\u00e9es sur tous ces projets? S’agit-il de donn\u00e9es provenant de projets aux EU ?<\/em><\/p>\nJ’ai travaill\u00e9 chez IBM et ITT et eu acc\u00e8s \u00e0 toutes leurs donn\u00e9es internes. J’ai \u00e9galement eu une \u00e9quipe d’une dizaine de consultants apportant des donn\u00e9es de 25 \u00e0 75 projets par mois pour des centaines d’entreprises. J’ai travaill\u00e9 dans 24 pays, mais environ 90% des donn\u00e9es de la table pr\u00e9c\u00e9dente proviennent des \u00c9tats-Unis<\/em>.<\/p>\nLes meilleurs pays pour la qualit\u00e9 sont le Japon et l’Inde. La productivit\u00e9 est une question plus complexe en raison des grandes variations dans les heures de travail. Aux \u00c9tats-Unis, nous avons une semaine nominale de 40 heures, elle est de 44 heures au Japon, seulement 36 heures au Canada. Il ya aussi de grandes diff\u00e9rences dans les vacances et les jours f\u00e9ri\u00e9s. C’est trop compliqu\u00e9 pour une r\u00e9ponse rapide.<\/em><\/p>\nQ: Vous dites que 10 000 FP repr\u00e9sente environ 1 000 000 lignes de code. Est-ce une mesure que quelqu’un peut utiliser pour comparer ses projets avec ces donn\u00e9es, quand il n’a pas d’estimation en FP ? Ou existe-t-il une autre mesure, comme par exemple, la taille de l’\u00e9quipe de d\u00e9veloppement, ou les ann\u00e9es-hommes ?<\/em><\/p>\nLe ratio d’instructions de code source pour les points de fonction est appel\u00e9 \u00ab\u00a0backfired\u00a0\u00bb et a d’abord \u00e9t\u00e9 d\u00e9velopp\u00e9 dans les ann\u00e9es 1970 par IBM. Ce ratio varie selon les langages ou les combinaisons de langages. Pour le Cobol, il est d’environ 105,7 instructions par point de fonction; pour le C, environ 128 d\u00e9clarations par point de fonction; JAVA est autour de 53 instructions par point de fonction. Il existe plusieurs compagnies qui vendent des listes de ces ratios pour environ 1 000 langages de programmation.<\/em><\/p>\nVolume de d\u00e9fauts
\n<\/strong><\/h3>\nLors de l’examen des projets en difficult\u00e9, on v\u00e9rifie toujours que la raison principale du retard ou de l’abandon est due \u00e0 des volumes excessifs de d\u00e9fauts graves. Le tableau 2 montre les volumes moyens des d\u00e9fauts constat\u00e9s sur des projets logiciels, ainsi que le pourcentage de d\u00e9fauts enlev\u00e9s avant la livraison aux clients, pour diff\u00e9rentes origines de d\u00e9fauts.<\/p>\n
Table 2: Defect Removal Efficiency By Origin of Defects Circa 2012<\/strong><\/em><\/p>\n\n\nDefect Origins<\/strong><\/td>\nDefect potentials<\/strong><\/td>\nRemoval Efficiency<\/strong><\/td>\nDelivered Defects<\/strong><\/td>\n<\/tr>\n\nRequirements<\/td>\n 1.00<\/td>\n 77%<\/td>\n 0.23<\/td>\n<\/tr>\n \nDesign<\/td>\n 1.25<\/td>\n 85%<\/td>\n 0.19<\/td>\n<\/tr>\n \nCoding<\/td>\n 1.75<\/td>\n 95%<\/td>\n 0.09<\/td>\n<\/tr>\n \nDocument<\/td>\n 0.60<\/td>\n 80%<\/td>\n 0.12<\/td>\n<\/tr>\n \nBad Fixes<\/td>\n 0.40<\/td>\n 70%<\/td>\n 0.12<\/td>\n<\/tr>\n \nTotal<\/em><\/td>\n5.00<\/em><\/td>\n85%<\/em><\/td>\n0.75<\/em><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n(Data Expressed in Terms of Defects per Function Point)<\/p>\n
Q: Nous pouvons voir dans le tableau pr\u00e9c\u00e9dent que les d\u00e9fauts potentiels <\/em>de programmation sont sup\u00e9rieurs \u00e0 tous les autres. Avez-vous vu une \u00e9volution selon les diff\u00e9rentes technologies utilis\u00e9es sur les projets? Beaucoup de gens pensent que les nouvelles technologies, parce que plus complexe, sont susceptibles d’introduire plus de d\u00e9fauts.<\/em><\/p>\nLes erreurs de code sont principalement li\u00e9es au niveau des langages utilis\u00e9s. Chaque source de d\u00e9fauts est affect\u00e9e par la complexit\u00e9 et les applications multi-tiers comme le client-serveur ont tendance \u00e0 avoir plus de defauts de sp\u00e9cifications (Requirements) et de conception (Design).<\/em><\/p>\nQ: On peut voir \u00e9galement que les d\u00e9fauts de Requirements et de Design sont plus nombreux que les d\u00e9fauts de code. M\u00eame question: avez-vous vu une \u00e9volution dans ce domaine ? Avec l’accent mis sur l’externalisation et l’outsourcing, certains pourraient penser que ces d\u00e9fauts se produisent de plus en plus fr\u00e9quemment.<\/em><\/p>\nIl existe des outils efficaces tels que FOG et FLESCH<\/em>, des outils d’analyse statique de texte ou d’analyse UML qui peuvent r\u00e9duire les d\u00e9fauts de sp\u00e9cifications. Ainsi que les outils de mod\u00e9lisation des requirements et de conception. Les utilisateurs int\u00e9gr\u00e9s dans les processus Agile peuvent aider \u00e9galement, mais avec certaines limites. Aucun utilisateur ne peut comprendre \u00e0 lui toutes les fonctionnalit\u00e9s d’une application de 10 000 points de fonction ou 10 000 utilisateurs.<\/em><\/p>\nL’industrie du logiciel devrait utiliser des outils modernes de sp\u00e9cification et de conception en 3D, et pas seulement du texte et des diagrammes statiques. Si vous utilisez les m\u00e9thodes appropri\u00e9es, vous aurez un haut niveau de qualit\u00e9 et des planning plus courts \u00e9galement.<\/em><\/p>\nDe par mon travail d’expert dans des proc\u00e8s pour cause de projets en difficult\u00e9, j’ai pu constater que la plupart \u00e9chouent en raison de contr\u00f4les de qualit\u00e9 m\u00e9diocres. Trop de bugs pr\u00e9sents avant que ne commence la phase de test aboutissent \u00e0 \u00e9tendre les cycles de projet de mani\u00e8re presque infinie.<\/em><\/p>\nDeux strat\u00e9gies g\u00e9n\u00e9rales sont n\u00e9cessaires pour atteindre la qualit\u00e9:<\/p>\n
\n- R\u00e9duire les volumes de d\u00e9fauts existants ou potentiels.<\/li>\n
- Accro\u00eetre l’efficacit\u00e9 de suppression des d\u00e9fauts (Defect Removal Efficiency ou DRE) \u2013 \u00e1 noter que celle-ci n’est pas tr\u00e8s efficace pour les d\u00e9fauts autres que de code.<\/li>\n<\/ol>\n
R\u00e9duire le volume des d\u00e9fauts
\n<\/strong><\/h3>\nCertaines des m\u00e9thodes qui permettent de r\u00e9duire les d\u00e9fauts :<\/p>\n
\n- Mod\u00e9lisation des sp\u00e9cifications.<\/li>\n
- Outils d’analyse statique des sp\u00e9cifications, qui permettent de trouver des erreurs et des ambigu\u00eft\u00e9s.<\/li>\n
- Formalisation des sp\u00e9cifications et inspection des requirements et de la mod\u00e9lisation fonctionnelle.<\/li>\n
- Incorporation des utilisateurs au projet, comme on le trouve dans les processus Agile.<\/li>\n
- D\u00e9veloppement \u00e0 base de tests, quand la phase de conception est pr\u00e9c\u00e9d\u00e9e par la d\u00e9finition des cas de tests.<\/li>\n
- Prototypage, afin de minimiser les \u00e9volutions de sp\u00e9cifications.<\/li>\n
- Examen formalis\u00e9 de toutes les demandes de changement (Change Requests).<\/li>\n
- Outils de contr\u00f4les automatis\u00e9s des changements, avec des r\u00e9f\u00e9rences crois\u00e9es.<\/li>\n<\/ul>\n
Lorsque les inspections formelles sont ajout\u00e9s au cycle, les d\u00e9fauts potentiels diminuent progressivement, passant de 5 par point de fonction \u00e0 3, alors que les niveaux d’efficacit\u00e9 d’\u00e9limination de d\u00e9fauts (DRE) sont syst\u00e9matiquement sup\u00e9rieurs \u00e0 95% voire atteignent 99%.<\/p>\n
L’analyse de code est une forme relativement nouvelle d’\u00e9liminer des d\u00e9fauts, qui pr\u00e9sente \u00e9galement des avantages en termes de pr\u00e9vention de ceux-ci.<\/p>\n
Un aspect int\u00e9ressant des contr\u00f4les des sp\u00e9cifications est la r\u00e9duction des modifications impr\u00e9vues de requirements. Les projets o\u00f9 les sp\u00e9cifications sont soigneusement pr\u00e9cis\u00e9es et analys\u00e9es connaissent en moyenne seulement une fraction de 1% de changements impr\u00e9vus par mois.<\/p>\n
Relever l’efficacit\u00e9 de l’\u00e9limination des d\u00e9fauts
\n<\/strong><\/h3>\nDe nombreuses formes de tests r\u00e9alis\u00e9s par les d\u00e9veloppeurs pr\u00e9sentent moins de 35% d’efficacit\u00e9 \u00e0 d\u00e9tecter des bugs ou des d\u00e9fauts, m\u00eame si parfois ils peuvent atteindre les 50%. Les tests \u00e1 base de sc\u00e9narios de test mis en oeuvre par des testeurs certifi\u00e9s perment de d\u00e9passer souvent les 50%.<\/p>\n
Une phase de conception formelle et des inspections de code permettent d’atteindre 65% d’efficacit\u00e9 dans la d\u00e9tection des bugs ou des d\u00e9fauts, et parfois les 85%. Les inspections \u00e9galement peuvent augmenter cette efficacit\u00e9 en fournissant des sp\u00e9cifications plus compl\u00e8tes pour le personnel de QA.<\/p>\n
L’analyse de code permet \u00e9galement un niveau d’efficacit\u00e9 \u00e9lev\u00e9 de suppression de nombreux d\u00e9fauts de programmation. Par cons\u00e9quent, les projets de premier plan dans les entreprises leaders utilisent des combinaisons synergiques \u00e1 base d’inspections formelles, d’analyse de code et de tests.<\/p>\n
Cette combinaison est le seul moyen connu d’atteindre des niveaux d’\u00e9limination des d\u00e9fauts sup\u00e9rieurs \u00e0 98%, conduit \u00e0 des d\u00e9lais de d\u00e9veloppement plus courts et diminue les risques d’\u00e9chec des projets.<\/p>\n
Q: Parmi ces m\u00e9thodes, certaines sont automatis\u00e9es et donc devraient \u00eatre moins co\u00fbteuses alors que d’autres \u2013 telles que la conception formelle et les inspections de code \u2013 ne peuvent l’\u00eatre, et sont donc probablement plus co\u00fbteuse. Avez-vous d\u00e9j\u00e0 essay\u00e9 de d\u00e9finir un rapport entre le co\u00fbt et l’efficacit\u00e9 de ces m\u00e9thodes ?<\/em><\/p>\nVous vous trompez. Avant qu’IBM n’introduise les inspections pour une application de base de donn\u00e9es, les tests duraient 3 mois. Apr\u00e8s la mise en oeuvre d’inspections, la phase de QA est descendue \u00e0 1 mois. Les inspections prenaient environ 6 semaines. Il ya eu une r\u00e9duction nette des co\u00fbts et des d\u00e9lais et une augmentation de l’efficacit\u00e9 de l’\u00e9limination des d\u00e9fauts de moins 85% \u00e0 plus de 95% dans le m\u00eame temps.<\/em><\/p>\nVotre question refl\u00e8te un probl\u00e8me courant: la plupart des entreprises ne mesurent pas suffisamment bien pour disposer de donn\u00e9es qui permettent de comprendre l’\u00e9conomie de la qualit\u00e9. J’ai des donn\u00e9es sur les co\u00fbts comparatifs de chaque combinaison d’inspections pr\u00e9-test, d’analyse de code et de tests. Les meilleurs r\u00e9sultats proviennent d’une combinaison synergique de pr\u00e9vention des d\u00e9fauts, d’\u00e9limination ce ceux-ci avant la phase de test, et de tests r\u00e9alis\u00e9s par un personnel de QA certifi\u00e9.<\/em><\/p>\nLes pires r\u00e9sultats proviennent de tests r\u00e9alis\u00e9s uniquement par les d\u00e9veloppeurs ou par du personnel de QA amateur, sans aucune inspection pr\u00e9-test ou d’analyse de code. Tout le monde devrait savoir cela, mais les donn\u00e9es et les mesures sont si pauvres que la plupart des managers n’en ont pas la moindre id\u00e9e.<\/em><\/p>\nQ: Diriez-vous que l’efficacit\u00e9 de ces m\u00e9thodes varie en fonction de la taille d’un projet ? On peut penser instinctivement que plus le projet est important, plus le risque de trouver des d\u00e9fauts de sp\u00e9cifications et de conception est \u00e9lev\u00e9, tandis que le niveau d’erreurs de code devrait rester (plus ou moins) stable ?<\/em><\/p>\nLorsque les applications croissent en taille, les d\u00e9fauts potentiels <\/em>deviennent plus importants et l’efficacit\u00e9 d’\u00e9limination de ces d\u00e9fauts devient plus faible. C’est pourquoi les inspections pr\u00e9-test et l’analyse de code sont de plus en plus pr\u00e9cieux lorsque la taille des applications devient plus importante.<\/em><\/p>\nQ: Je dirais que pour les grands projets, il est recommand\u00e9 d’industrialiser l’ensemble de ces m\u00e9thodes. Mais pour les projets de petite taille ou de taille moyenne, ou pour une \u00e9quipe qui n’est pas habitu\u00e9e \u00e0 utiliser ces m\u00e9thodes, en recommanderiez-vous certaines que vous jugez plus faciles \u00e0 mettre en \u0153uvre en premier <\/em>ou plus importantes ? Pour le dire autrement, existe-t-il un chemin optimal vers la maturit\u00e9 ?<\/em><\/p>\nIl s’agit l\u00e1 d’une question trop compliqu\u00e9e pour pouvoir r\u00e9pondre de mani\u00e8re courte. L’analyse de code ne co\u00fbte pas cher, eset efficace et facile \u00e0 utiliser sur les projets de toutes tailles. En dessous de 1 000 points de fonction, Agile est Ok; au-dessus de 10 000 points de fonction, TSP est meilleur. Ce dont les entreprises ont besoin ne sont pas de r\u00e9ponses g\u00e9n\u00e9rales mais de pr\u00e9dictions pr\u00e9cises qui montrent l’ensemble des m\u00e9thodes optimales pour des projets sp\u00e9cifiques. Mon travail principal est de construire des outils qui permettent de pr\u00e9dire des r\u00e9sultats sp\u00e9cifiques pour des projets sp\u00e9cifiques.<\/em><\/p>\nQ: Derni\u00e8re question, pour conclure, et sans doute celle que la plupart des gens sont curieux de savoir : qu’est-ce qu’une journ\u00e9e typique pour vous? Faire du consulting pour un client? Travailler sur un document ou un nouveau livre? Aller \u00e0 la p\u00eache ou jouer au golf?<\/em><\/p>\nIl ya des ann\u00e9es, quand je travaillais sur mon premier livre, je devais \u00eatre au travail vers 8h30 alors j’ai commenc\u00e9 \u00e0 me lever t\u00f4t pour \u00e9crire \u00e0 5 heures. Apr\u00e8s 15 livres, je ne peux plus dormir tard. J’ai l’habitude d’\u00e9crire des livres ou des articles entre 4 heures et 10 heures du matin; je passe \u00e0 une activit\u00e9 \u00e0 base de logiciels ou centr\u00e9e sur le business de 10 heures \u00e0 16 heures, et ensuite je me repose ou joue au golf tard dans la journ\u00e9e. Je vais aussi \u00e0 un gymnase trois fois par semaine.<\/em><\/p>\nLa plupart de mon activit\u00e9 de conseil ou de mes pr\u00e9sentations s’effectuent \u00e0 l’\u00e9tranger. Le 8 novembre, je participe \u00e0 une conf\u00e9rence \u00e0 Stockholm, en Su\u00e8de. Le sujet est \u201cAchieving Software Excellence\u201d. Le 13 novembre, j’effectue un webinar sur \u201cSoftware Risk and Value Analysis\u201d. Le 4 d\u00e9cembre, un webcast pour IBM intitul\u00e9 \u201cMeasuring Software Quality and Customer Satisfaction\u201d.<\/em><\/em><\/p>\nJe voyage pour les conf\u00e9rences les plus importantes telles que le Japanese Symposium on Software Testing, le Malaysian Testing Conference, et diff\u00e9rentes conf\u00e9rences du International Function Point Users Group.<\/em><\/p>\nCapers, merci pour le mat\u00e9riel que vous m’avez envoy\u00e9 et pour avoir pris le temps de r\u00e9pondre \u00e0 mes questions.<\/p>\n","protected":false},"excerpt":{"rendered":"
J’ai re\u00e7u des documents de Capers Jones, auteur bien connu et conf\u00e9rencier international, qu’il n’ai pas n\u00e9cessaire de pr\u00e9senter, mais au cas o\u00f9 : http:\/\/www.namcook.com\/aboutus.html). Capers Jones est vice president et CTO de Namcook Analytics LLC. Ce mat\u00e9riel constitue une bonne synth\u00e8se de l’\u00e9tat actuel de la qualit\u00e9 du logiciel, dont je vais r\u00e9sumer […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-232","post","type-post","status-publish","format-standard","hentry","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/232"}],"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=232"}],"version-history":[{"count":1,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/232\/revisions"}],"predecessor-version":[{"id":233,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/232\/revisions\/233"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=232"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
| <\/td>\n | Early<\/strong><\/td>\n| On-Time<\/strong><\/td>\n | Delayed<\/strong><\/td>\n | Canceled<\/strong><\/td>\n<\/tr>\n | 1 FP<\/td>\n | 14.68%<\/td>\n | 83.16%<\/td>\n | 1.92%<\/td>\n | 0.25%<\/td>\n<\/tr>\n | 10 FP<\/td>\n | 11.08%<\/td>\n | 81.25%<\/td>\n | 5.67%<\/td>\n | 2.00%<\/td>\n<\/tr>\n | 100 FP<\/td>\n | 6.06%<\/td>\n | 74.77%<\/td>\n | 11.83%<\/td>\n | 7.33%<\/td>\n<\/tr>\n | 1 000 FP<\/td>\n | 1.24%<\/td>\n | 60.76%<\/td>\n | 17.67%<\/td>\n | 20.33%<\/td>\n<\/tr>\n | 10 000 FP<\/td>\n | 0.14%<\/td>\n | 28.03%<\/td>\n | 23.83%<\/td>\n | 48.00%<\/td>\n<\/tr>\n | 100 000 FP<\/td>\n | 0.00%<\/td>\n | 13.67%<\/td>\n | 21.33%<\/td>\n | 65.00%<\/td>\n<\/tr>\n | Average<\/em><\/td>\n | 5.53%<\/em><\/td>\n | 56.94%<\/em><\/td>\n | 13.71%<\/em><\/td>\n | 23.82%<\/em><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n | Q: Capers, comment avez-vous r\u00e9ussi \u00e0 obtenir toutes ces donn\u00e9es sur tous ces projets? S’agit-il de donn\u00e9es provenant de projets aux EU ?<\/em><\/p>\n J’ai travaill\u00e9 chez IBM et ITT et eu acc\u00e8s \u00e0 toutes leurs donn\u00e9es internes. J’ai \u00e9galement eu une \u00e9quipe d’une dizaine de consultants apportant des donn\u00e9es de 25 \u00e0 75 projets par mois pour des centaines d’entreprises. J’ai travaill\u00e9 dans 24 pays, mais environ 90% des donn\u00e9es de la table pr\u00e9c\u00e9dente proviennent des \u00c9tats-Unis<\/em>.<\/p>\n Les meilleurs pays pour la qualit\u00e9 sont le Japon et l’Inde. La productivit\u00e9 est une question plus complexe en raison des grandes variations dans les heures de travail. Aux \u00c9tats-Unis, nous avons une semaine nominale de 40 heures, elle est de 44 heures au Japon, seulement 36 heures au Canada. Il ya aussi de grandes diff\u00e9rences dans les vacances et les jours f\u00e9ri\u00e9s. C’est trop compliqu\u00e9 pour une r\u00e9ponse rapide.<\/em><\/p>\n Q: Vous dites que 10 000 FP repr\u00e9sente environ 1 000 000 lignes de code. Est-ce une mesure que quelqu’un peut utiliser pour comparer ses projets avec ces donn\u00e9es, quand il n’a pas d’estimation en FP ? Ou existe-t-il une autre mesure, comme par exemple, la taille de l’\u00e9quipe de d\u00e9veloppement, ou les ann\u00e9es-hommes ?<\/em><\/p>\n Le ratio d’instructions de code source pour les points de fonction est appel\u00e9 \u00ab\u00a0backfired\u00a0\u00bb et a d’abord \u00e9t\u00e9 d\u00e9velopp\u00e9 dans les ann\u00e9es 1970 par IBM. Ce ratio varie selon les langages ou les combinaisons de langages. Pour le Cobol, il est d’environ 105,7 instructions par point de fonction; pour le C, environ 128 d\u00e9clarations par point de fonction; JAVA est autour de 53 instructions par point de fonction. Il existe plusieurs compagnies qui vendent des listes de ces ratios pour environ 1 000 langages de programmation.<\/em><\/p>\n Lors de l’examen des projets en difficult\u00e9, on v\u00e9rifie toujours que la raison principale du retard ou de l’abandon est due \u00e0 des volumes excessifs de d\u00e9fauts graves. Le tableau 2 montre les volumes moyens des d\u00e9fauts constat\u00e9s sur des projets logiciels, ainsi que le pourcentage de d\u00e9fauts enlev\u00e9s avant la livraison aux clients, pour diff\u00e9rentes origines de d\u00e9fauts.<\/p>\n Table 2: Defect Removal Efficiency By Origin of Defects Circa 2012<\/strong><\/em><\/p>\n (Data Expressed in Terms of Defects per Function Point)<\/p>\n Q: Nous pouvons voir dans le tableau pr\u00e9c\u00e9dent que les d\u00e9fauts potentiels <\/em>de programmation sont sup\u00e9rieurs \u00e0 tous les autres. Avez-vous vu une \u00e9volution selon les diff\u00e9rentes technologies utilis\u00e9es sur les projets? Beaucoup de gens pensent que les nouvelles technologies, parce que plus complexe, sont susceptibles d’introduire plus de d\u00e9fauts.<\/em><\/p>\n Les erreurs de code sont principalement li\u00e9es au niveau des langages utilis\u00e9s. Chaque source de d\u00e9fauts est affect\u00e9e par la complexit\u00e9 et les applications multi-tiers comme le client-serveur ont tendance \u00e0 avoir plus de defauts de sp\u00e9cifications (Requirements) et de conception (Design).<\/em><\/p>\n Q: On peut voir \u00e9galement que les d\u00e9fauts de Requirements et de Design sont plus nombreux que les d\u00e9fauts de code. M\u00eame question: avez-vous vu une \u00e9volution dans ce domaine ? Avec l’accent mis sur l’externalisation et l’outsourcing, certains pourraient penser que ces d\u00e9fauts se produisent de plus en plus fr\u00e9quemment.<\/em><\/p>\n Il existe des outils efficaces tels que FOG et FLESCH<\/em>, des outils d’analyse statique de texte ou d’analyse UML qui peuvent r\u00e9duire les d\u00e9fauts de sp\u00e9cifications. Ainsi que les outils de mod\u00e9lisation des requirements et de conception. Les utilisateurs int\u00e9gr\u00e9s dans les processus Agile peuvent aider \u00e9galement, mais avec certaines limites. Aucun utilisateur ne peut comprendre \u00e0 lui toutes les fonctionnalit\u00e9s d’une application de 10 000 points de fonction ou 10 000 utilisateurs.<\/em><\/p>\n L’industrie du logiciel devrait utiliser des outils modernes de sp\u00e9cification et de conception en 3D, et pas seulement du texte et des diagrammes statiques. Si vous utilisez les m\u00e9thodes appropri\u00e9es, vous aurez un haut niveau de qualit\u00e9 et des planning plus courts \u00e9galement.<\/em><\/p>\n De par mon travail d’expert dans des proc\u00e8s pour cause de projets en difficult\u00e9, j’ai pu constater que la plupart \u00e9chouent en raison de contr\u00f4les de qualit\u00e9 m\u00e9diocres. Trop de bugs pr\u00e9sents avant que ne commence la phase de test aboutissent \u00e0 \u00e9tendre les cycles de projet de mani\u00e8re presque infinie.<\/em><\/p>\n Deux strat\u00e9gies g\u00e9n\u00e9rales sont n\u00e9cessaires pour atteindre la qualit\u00e9:<\/p>\n Certaines des m\u00e9thodes qui permettent de r\u00e9duire les d\u00e9fauts :<\/p>\n Lorsque les inspections formelles sont ajout\u00e9s au cycle, les d\u00e9fauts potentiels diminuent progressivement, passant de 5 par point de fonction \u00e0 3, alors que les niveaux d’efficacit\u00e9 d’\u00e9limination de d\u00e9fauts (DRE) sont syst\u00e9matiquement sup\u00e9rieurs \u00e0 95% voire atteignent 99%.<\/p>\n L’analyse de code est une forme relativement nouvelle d’\u00e9liminer des d\u00e9fauts, qui pr\u00e9sente \u00e9galement des avantages en termes de pr\u00e9vention de ceux-ci.<\/p>\n Un aspect int\u00e9ressant des contr\u00f4les des sp\u00e9cifications est la r\u00e9duction des modifications impr\u00e9vues de requirements. Les projets o\u00f9 les sp\u00e9cifications sont soigneusement pr\u00e9cis\u00e9es et analys\u00e9es connaissent en moyenne seulement une fraction de 1% de changements impr\u00e9vus par mois.<\/p>\n De nombreuses formes de tests r\u00e9alis\u00e9s par les d\u00e9veloppeurs pr\u00e9sentent moins de 35% d’efficacit\u00e9 \u00e0 d\u00e9tecter des bugs ou des d\u00e9fauts, m\u00eame si parfois ils peuvent atteindre les 50%. Les tests \u00e1 base de sc\u00e9narios de test mis en oeuvre par des testeurs certifi\u00e9s perment de d\u00e9passer souvent les 50%.<\/p>\n Une phase de conception formelle et des inspections de code permettent d’atteindre 65% d’efficacit\u00e9 dans la d\u00e9tection des bugs ou des d\u00e9fauts, et parfois les 85%. Les inspections \u00e9galement peuvent augmenter cette efficacit\u00e9 en fournissant des sp\u00e9cifications plus compl\u00e8tes pour le personnel de QA.<\/p>\n L’analyse de code permet \u00e9galement un niveau d’efficacit\u00e9 \u00e9lev\u00e9 de suppression de nombreux d\u00e9fauts de programmation. Par cons\u00e9quent, les projets de premier plan dans les entreprises leaders utilisent des combinaisons synergiques \u00e1 base d’inspections formelles, d’analyse de code et de tests.<\/p>\n Cette combinaison est le seul moyen connu d’atteindre des niveaux d’\u00e9limination des d\u00e9fauts sup\u00e9rieurs \u00e0 98%, conduit \u00e0 des d\u00e9lais de d\u00e9veloppement plus courts et diminue les risques d’\u00e9chec des projets.<\/p>\n Q: Parmi ces m\u00e9thodes, certaines sont automatis\u00e9es et donc devraient \u00eatre moins co\u00fbteuses alors que d’autres \u2013 telles que la conception formelle et les inspections de code \u2013 ne peuvent l’\u00eatre, et sont donc probablement plus co\u00fbteuse. Avez-vous d\u00e9j\u00e0 essay\u00e9 de d\u00e9finir un rapport entre le co\u00fbt et l’efficacit\u00e9 de ces m\u00e9thodes ?<\/em><\/p>\n Vous vous trompez. Avant qu’IBM n’introduise les inspections pour une application de base de donn\u00e9es, les tests duraient 3 mois. Apr\u00e8s la mise en oeuvre d’inspections, la phase de QA est descendue \u00e0 1 mois. Les inspections prenaient environ 6 semaines. Il ya eu une r\u00e9duction nette des co\u00fbts et des d\u00e9lais et une augmentation de l’efficacit\u00e9 de l’\u00e9limination des d\u00e9fauts de moins 85% \u00e0 plus de 95% dans le m\u00eame temps.<\/em><\/p>\n Votre question refl\u00e8te un probl\u00e8me courant: la plupart des entreprises ne mesurent pas suffisamment bien pour disposer de donn\u00e9es qui permettent de comprendre l’\u00e9conomie de la qualit\u00e9. J’ai des donn\u00e9es sur les co\u00fbts comparatifs de chaque combinaison d’inspections pr\u00e9-test, d’analyse de code et de tests. Les meilleurs r\u00e9sultats proviennent d’une combinaison synergique de pr\u00e9vention des d\u00e9fauts, d’\u00e9limination ce ceux-ci avant la phase de test, et de tests r\u00e9alis\u00e9s par un personnel de QA certifi\u00e9.<\/em><\/p>\n Les pires r\u00e9sultats proviennent de tests r\u00e9alis\u00e9s uniquement par les d\u00e9veloppeurs ou par du personnel de QA amateur, sans aucune inspection pr\u00e9-test ou d’analyse de code. Tout le monde devrait savoir cela, mais les donn\u00e9es et les mesures sont si pauvres que la plupart des managers n’en ont pas la moindre id\u00e9e.<\/em><\/p>\n Q: Diriez-vous que l’efficacit\u00e9 de ces m\u00e9thodes varie en fonction de la taille d’un projet ? On peut penser instinctivement que plus le projet est important, plus le risque de trouver des d\u00e9fauts de sp\u00e9cifications et de conception est \u00e9lev\u00e9, tandis que le niveau d’erreurs de code devrait rester (plus ou moins) stable ?<\/em><\/p>\n Lorsque les applications croissent en taille, les d\u00e9fauts potentiels <\/em>deviennent plus importants et l’efficacit\u00e9 d’\u00e9limination de ces d\u00e9fauts devient plus faible. C’est pourquoi les inspections pr\u00e9-test et l’analyse de code sont de plus en plus pr\u00e9cieux lorsque la taille des applications devient plus importante.<\/em><\/p>\n Q: Je dirais que pour les grands projets, il est recommand\u00e9 d’industrialiser l’ensemble de ces m\u00e9thodes. Mais pour les projets de petite taille ou de taille moyenne, ou pour une \u00e9quipe qui n’est pas habitu\u00e9e \u00e0 utiliser ces m\u00e9thodes, en recommanderiez-vous certaines que vous jugez plus faciles \u00e0 mettre en \u0153uvre en premier <\/em>ou plus importantes ? Pour le dire autrement, existe-t-il un chemin optimal vers la maturit\u00e9 ?<\/em><\/p>\n Il s’agit l\u00e1 d’une question trop compliqu\u00e9e pour pouvoir r\u00e9pondre de mani\u00e8re courte. L’analyse de code ne co\u00fbte pas cher, eset efficace et facile \u00e0 utiliser sur les projets de toutes tailles. En dessous de 1 000 points de fonction, Agile est Ok; au-dessus de 10 000 points de fonction, TSP est meilleur. Ce dont les entreprises ont besoin ne sont pas de r\u00e9ponses g\u00e9n\u00e9rales mais de pr\u00e9dictions pr\u00e9cises qui montrent l’ensemble des m\u00e9thodes optimales pour des projets sp\u00e9cifiques. Mon travail principal est de construire des outils qui permettent de pr\u00e9dire des r\u00e9sultats sp\u00e9cifiques pour des projets sp\u00e9cifiques.<\/em><\/p>\n Q: Derni\u00e8re question, pour conclure, et sans doute celle que la plupart des gens sont curieux de savoir : qu’est-ce qu’une journ\u00e9e typique pour vous? Faire du consulting pour un client? Travailler sur un document ou un nouveau livre? Aller \u00e0 la p\u00eache ou jouer au golf?<\/em><\/p>\n Il ya des ann\u00e9es, quand je travaillais sur mon premier livre, je devais \u00eatre au travail vers 8h30 alors j’ai commenc\u00e9 \u00e0 me lever t\u00f4t pour \u00e9crire \u00e0 5 heures. Apr\u00e8s 15 livres, je ne peux plus dormir tard. J’ai l’habitude d’\u00e9crire des livres ou des articles entre 4 heures et 10 heures du matin; je passe \u00e0 une activit\u00e9 \u00e0 base de logiciels ou centr\u00e9e sur le business de 10 heures \u00e0 16 heures, et ensuite je me repose ou joue au golf tard dans la journ\u00e9e. Je vais aussi \u00e0 un gymnase trois fois par semaine.<\/em><\/p>\n La plupart de mon activit\u00e9 de conseil ou de mes pr\u00e9sentations s’effectuent \u00e0 l’\u00e9tranger. Le 8 novembre, je participe \u00e0 une conf\u00e9rence \u00e0 Stockholm, en Su\u00e8de. Le sujet est \u201cAchieving Software Excellence\u201d. Le 13 novembre, j’effectue un webinar sur \u201cSoftware Risk and Value Analysis\u201d. Le 4 d\u00e9cembre, un webcast pour IBM intitul\u00e9 \u201cMeasuring Software Quality and Customer Satisfaction\u201d.<\/em><\/em><\/p>\n Je voyage pour les conf\u00e9rences les plus importantes telles que le Japanese Symposium on Software Testing, le Malaysian Testing Conference, et diff\u00e9rentes conf\u00e9rences du International Function Point Users Group.<\/em><\/p>\n Capers, merci pour le mat\u00e9riel que vous m’avez envoy\u00e9 et pour avoir pris le temps de r\u00e9pondre \u00e0 mes questions.<\/p>\n","protected":false},"excerpt":{"rendered":" J’ai re\u00e7u des documents de Capers Jones, auteur bien connu et conf\u00e9rencier international, qu’il n’ai pas n\u00e9cessaire de pr\u00e9senter, mais au cas o\u00f9 : http:\/\/www.namcook.com\/aboutus.html). Capers Jones est vice president et CTO de Namcook Analytics LLC. Ce mat\u00e9riel constitue une bonne synth\u00e8se de l’\u00e9tat actuel de la qualit\u00e9 du logiciel, dont je vais r\u00e9sumer […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-232","post","type-post","status-publish","format-standard","hentry","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/232"}],"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=232"}],"version-history":[{"count":1,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/232\/revisions"}],"predecessor-version":[{"id":233,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/232\/revisions\/233"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=232"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}} |