BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Évaluation de l'Agilité et Scrum par rapport à d'autres méthodes de développement logiciel

Évaluation de l'Agilité et Scrum par rapport à d'autres méthodes de développement logiciel

En général, choisir une méthode de développement logiciel ressemble plus à joindre un culte qu'à faire un choix technologique approprié. Plusieurs entreprises n'essaient même pas d'évaluer les méthodes mais choisissent la plus populaire, qui de nos jours est une des nombreuses variantes agiles. Cet article utilise plusieurs métriques standardisées telles que les points de fonction, "defect removal efficiency (DRE)", "Cost of Quality (COQ)", Coût total de propriété (TCO) afin de comparer entre elles quelques méthodes de développement logiciel contemporaines.

On dénombre quelque 55 méthodes de développement logiciel identifiées et utilisées de nos jours et un plus grand nombre de méthodes hybrides. On retrouve par exemple : l'approche traditionnelle en cascade, différentes saveurs d'agile, le Rational Unified Process (RUP), le Team Software Process (TSP), la méthode en V, le Microsoft Solutions Framework, le Structured Analysis and Design Technique (SADT), l'Evolutionary Development (EVO), l'eXtreme Programming (XP), PRINCE2, Merise, développement par la modélisation, et beaucoup d'autres.

Les données parviennent d'études faites auprès de clients utilisant une myriade de méthodes de développement. Les prévisions sont faites à l'aide de l'outil propriétaire de l'auteur, "Software Risk Master™", qui peut modéliser toutes les 55 méthodes de développement logiciel.

Introduction

Le fait qu'il existe 55 méthodes de développement logiciel ayant chacune son lot de praticiens fidèles, atteste du fait que nulle d'entre elles ne convient à tous les types d'applications.

Certaines méthodes conviennent mieux à des petites applications et de petites équipes, d'autres fonctionnent pour les grands systèmes et les grandes équipes, d'autres encore sied mieux à des applications embarquées complexes, tandis que certaines autres conviennent au développement web hyper-rapide, alors que d'autres s'appliquent aux applications militaires hautement sécurisées. Comment est-ce possible de choisir la meilleure méthode pour un projet donné ? Est-ce qu'une méthode suffit ou faut-il que les entreprises en utilisent plusieurs selon la nature des projets qu'elles développent ?

Malheureusement, à cause du manque de données quantifiées et de comparaisons des méthodes, le choix d'une méthode de développement s'apparente plus à l'adhésion à un culte qu'à un choix technologique. Plusieurs entreprises n'essaient même pas d'évaluer des méthodes alternatives, mais adoptent plutôt la méthode la plus en vogue du moment indépendamment du fait qu'elle convienne ou non aux types de logiciels qu'elles développent.

L'évaluation des méthode de développement logiciel rappelle l'ancienne parabole bouddhiste des vieillards aveugles et de l'éléphant. Certaines méthodes sont les plus rapides, d'autres ont la meilleure qualité et d'autres le plus bas coût total de propriété.

(Dans la parabole originale l'homme aveugle qui touchait la trompe de l'éléphant pensait qu'un éléphant était comme une sorte de serpent. L'aveugle qui touchait son flanc pensait que l'éléphant était une sorte de mur. L'homme aveugle qui touchait la défense de l'éléphant pensait que c'était comme une lance; celui qui touchait sa queue pensait qu'un éléphant était comme une corde.)

Combinaison de facteurs impactant les projets logiciel

Idéalement on évaluerait plusieurs méthodes appliquées au développement de différents types d'applications. Ce n'est toutefois pas pratique dû à la complexité de gérer toutes les combinaisons possibles. Considérons les facteurs clés réputés pour avoir un impact sur les résultats de projets informatiques :

Facteur Nombre de possibilités
Méthodes 55
Langages de programmation 50
Nature, classe et type d'application 15
Niveau CMMI 5
Maturité de l'équipe (bas, moyen, élevé) 3
Taille de l'application (petite, moyenne, grande) 3
Complexité de l'application (basse, moyenne, élevée) 3
Nombres de combinaisons 5 568 750

Puisque le nombre de combinaisons énorme empêche de considérer chacun d'entre elles, cet article fait des hypothèses réductrices afin de focaliser principalement sur les méthodes et non les autres facteurs.

Les hypothèses de base de cet article sont :

  • Taille de l'application : 1000 points de fonction

  • Langage de programmation : C et C++

  • Instructions logiques : 75 000

  • Exigences nouvelles : omises

  • Fonctionnalités différées : omises

  • Fonctionnalités réutilisables : omises

  • Maturité de l'équipe : moyenne

  • Complexité : Moyenne

  • Coût mensuel : $ 7 500

En gardant taille, langage, complexité et maturité de l'équipe constants il est plus facile d'examiner l'impact des méthodes. Il y a malheureusement trop de méthodes pour les inclure toutes, nous allons donc présenter les résultats pour 10 parmi les plus utilisées au États-Unis.

(À noter que la taille des applications comparées varie de 800 à 1300 points de fonction. L'auteur a utilisé un procédé propriétaire pour ajuster et fixer mathématiquement la taille des applications afin de permettre les comparaisons côte-à-côte.)

Méthodes (Ordre alphabétique en anglais)

  1. Agile avec Scrum
  2. CMMI 1 séquentiel
  3. CMMI 3 itératif
  4. CMMI 5 spirale
  5. Extreme Programming (XP)
  6. Développement Orienté Objet
  7. Programmation en binôme avec méthode itérative
  8. Preuves d'adéquation avec waterfall
  9. Rational Unified Process (RUP)
  10. Team Software Process (TSP)

Suit une brève description des méthodes présentées dans cet article.

Agile avec scrum : Le terme "agile" est ambigu et il existe de nombreuses variantes de l'agilité. Pour cet article, le terme désigne des projets qui ont adopté le manifeste agile dans sa version de 1997, ont fait usage d'utilisateurs finaux comme source des exigences, ont utilisé des user stories, ont segmenté le projet en itérations distinctes développées individuellement, et ont utilisé les concepts de scrum et les réunions de rapport quotidien. Minimiser la production de documents papier et accélérer le développement sont les buts premiers de l'agilité.

CMMI 1 séquentiel : Le Capability Maturity Model Integrated™ (CMMI) du Software Engineering Institute est une méthode reconnue pour évaluer le niveau de sophistication du développement logiciel. CMMI 1 est le premier des 5 niveaux CMMI et signifie un développement chaotique. Le terme séquentiel réfère aux pratiques traditionnelles de développement logiciel débutant avec la spécification des exigences et procédant séquentiellement par étapes terminant complètement chaque étape avant le début de la suivante.

CMMI 3 itératif : Le troisième niveau du CMMI est désigné "ajusté" et réfère à une ensemble d'activités de développement assez régulières et bien comprises. Le terme itératif précède les méthodes agiles mais signifie également la division des applications en morceaux distincts pouvant être bâtis individuellement.

CMMI 5 spiral : Le niveau 5 du CMMI est le niveau le plus élevé et est désigné "en optimisation". Les équipes qui on atteint ce niveau sont très sophistiquées et ne font que rarement des erreurs graves. La méthode en spirale a été introduite par le Dr. Barry Boehm. Elle partage des concepts similaires avec les méthodes agiles tels que les segments pouvant être développés séparément. Les segments préconisés par la méthode en spirale durent souvent plus longtemps que les itérations agiles et sont précédés de prototypes.

Extreme Programming (XP) : Cette méthode fait partie des méthodes agiles mais présente certaines caractéristiques uniques. La plus notable des caractéristiques est le fait d'attendre que les tests unitaires ont été développés avant de commencer à coder les fonctionnalités. La méthode XP fait usage également de revues ou inspections. Des fois la programmation en binôme est utilisée en XP mais pas toujours, c'est donc un cas particulier. La qualité du logiciel est un but primordial de XP.

Le développement orienté objet : La méthode orientée objet est l'une des méthodes les plus anciennes présentées ici et a connu beaucoup de succès. Elle a également conduit à la création de langages de programmation tels que Objective C. Cet article utilise l'analyse et le design orienté objet avec les cas d'utilisation. Le langage C++ est aussi un langage orienté objet. L'analyse et le design orienté objet sont en quelque sorte différents des méthodes conventionnelles et requièrent une courbe d'apprentissage.

La programmation in binôme : Le concept de la programmation en binôme nous vient des méthodes agiles, mais ne s'y limitent pas. Dans cet article, la programmation en binôme est utilisée avec le développement itératif. L'idée de base de la programmation en binôme est que deux personnes codent à chacun leur tour. Quand l'une code, l'autre observe et suggère des améliorations. Des fois, la paire n'utilise qu'un ordinateur placé au milieu.

Preuves d'adéquation : Le concept de la preuve d'adéquation est le fait d'appliquer des preuves mathématiques aux algorithmes qui seront inclus dans un logiciel. Évidemment, les algorithmes doivent être exprimés de manière formelle de telle sorte qu'ils puissent être prouvés. Il est également évident que la personne qui effectue la preuve possède une grande expertise mathématique de manière à pouvoir travailler avec des équations et algorithmes complexes.

Rational Unified Process (RUP): La méthode RUP provient de Rational Corporation qui fut acquis par IBM en 2003 et est donc une technologie d'IBM. La méthode RUP contient des aspects à la fois de la méthode itérative et de la méthode orientée objet. Depuis que la méthode RUP appartient à IBM il y a de nombreux outils qui la supporte. Les cas d'utilisation et autres représentations visuelles sont présents dans la plupart des outils RUP, mais les clients de l'auteur ajoutent également d'autres outils tels que les tables de décisions.

Team Software Process (TSP) : La méthode TSP a été développé par le regretté Watts Humphrey qui fut le directeur du développement chez IBM et qui par la suite a créé la méthode d'évaluation utilisée par le Software Engineering Institue (SEI) dans son Capability Maturity Model. TSP est très focalisé sur la qualité du logiciel. Tous les bogues sont documentés, on fait usage des inspections et la qualité est l'objectif principal vu que les bogues ralentissent le développement. La méthode TSP a certains aspects inusités tels que des équipes (NdT: correction du traducteur) auto-gérées et un coach agissant comme gestionnaire. TSP est maintenant approuvé par le SEI.

Trois sortes d'évaluation méthodologique et 10 métriques

Même si les méthodes sont limitées à 10 il y a quand même de nombreux résultats à évaluer. Toutefois, pour avoir travaillé avec des centaines de client, les sujets les plus importants pour les directeurs du développement et exécutifs sont :

Métriques relatives à la rapidité

  1. Les délais
  2. La dotation
  3. L'effort
  4. Le coût

Métriques relatives à la qualité

  1. Le potentiel d'anomalies
  2. L'efficacité à réparer les anomalies (DRE)
  3. Les anomalies présentes lors de la livraison
  4. Les anomalies majeures

Métriques économiques

  1. Coût total de propriété (TCO)
  2. Coût de la qualité (COQ)

Même avec 10 méthodes et 10 sujets à présenter, c'est tout de même une quantité d'information significative.

Cet article tentera de comparer les méthodes dans trois grandes catégories :

  1. Rapidité : délais, effort et coûts du développement
  2. Qualité : qualité du logiciel en terme d'anomalies livrées
  3. Économie : coût total de propriété (TCO) et coût de la qualité (COQ)

Il est à noter que la technique utilisée dans cet article qui consiste à garder constante la taille des applications à 1000 points de fonction fait en sorte que les données ne peuvent être utilisées pour déterminer les meilleures méthodes pour les grands systèmes de 10 000 points de fonction ni les énormes systèmes de 100 000 points de fonction. Toutefois, les applications d'environ 1 000 points de fonction sont très courantes et sont assez grandes pour montrer des données comparatives de manière utile.

Certaines données présentées ici ont été préparées avec l'outil Software Risk Master™ que l'auteur a conçu pour effectuer des comparaisons côte-à-côte de n'importe quelle méthode, n'importe quel niveau CMMI, n'importe quelle complexité et n'importe quel degré de maturité d'équipe. Certains tableaux sont obtenus à partir des résultats de SRM, bien que dérivés d'applications mesurées précédemment.

Rapidité : Comparaison des délais et coûts de développement des méthodes

Tableau 1 : Délais, taille d'équipe, effort, productivité

  Méthode Délai (mois) Equipe Effort (mois) FP Coût de développement
1 XP 11,78 7 84 11,89 $630 860
2 Agile/Scrum 11,82 7 84 11,85 $633 043
3 TSP 12,02 7 86 11,64 $644 070
4 CMMI 5/Spiral 12,45 7 83 12,05 $622 257
5 OO 12,78 8 107 9,31 $805 156
6 RUP 13,11 8 101 9,58 $756 157
7 Binôme/itératif 13,15 12 155 9,21 $1 160 492
8 CMMI 3/itératif 13,34 8 107 9,37 $800 113
9 Preuves/Waterfall 13,71 12 161 6,21 $1 207 500
10 CMMI 1/Waterfall 15,85 10 158 6,51 $1 188 878
  Moyenne 13,00 8,6 112,6 9,762 $844 852

Comme on peut le voir, les méthodes donnant lieu aux plus courts délais pour des applications de 1000 points de fonction sont XP et les méthodes agiles. La méthode TSP arrive en troisième.

Qualité : Comparaison du potentiel d'anomalies, de la réparation d'anomalies et du nombre d'anomalies livrées

La prochaine caractéristique des méthodes qu'il est intéressant de comparer est celle de la qualité. L'article considère quatre aspects de la qualité logiciel : les anomalies potentielles, le taux de réparation des anomalies, le nombre d'anomalies présentes à la livraison et le nombre d'anomalies majeures.

Le terme "potentiel d'anomalies" désigne les défauts trouvés dans les exigences, le design, le code source, les documents et les mauvaises réparations. Une mauvaise réparation est un nouveau défaut accidentellement introduit lors d'une tentative de réparation d'un défaut existant. (A peu près 7% des tentatives de réparer les bogues en incluent de nouveaux.)

Le terme "efficacité de réparation des anomalies" désigne les niveaux d'efficacité combinés des revues, analyses statiques et tests. Dans cet article six types de tests sont inclus : 1) unitaires; 2) fonctionnels; 3) régression; 4) performance; 5) système; 6) acceptation.

(Il y a environ 40 types de tests, mais les types de tests spécialisés sont hors de la portée de cet article.)

Lorsqu'il considère la qualité évaluée le lecteur comprendra la raison de la citation des aveugles et de l'éléphant :

Tableau 2 : Potentiel, réparations et livraisons de défauts

  Méthode Potentiels Réparés Livrés Majeurs
1 TSP 2 700 96,79% 87 16
2 CMMI 5/Spiral 3 000 95,95% 122 22
3 RUP 3 900 95,07% 192 36
4 Extreme (XP) 4 500 93,36% 299 55
5 OO 4 950 93,74% 310 57
6 Binôme/itératif 4 700 92,93% 332 61
7 Preuves/Waterfall 4 650 92,21% 362 67
8 Agile/Scrum 4 800 92,30% 370 68
9 CMMI 3/itératif 4 500 91,18% 397 73
10 CMMI 1/Waterfall 6 000 78,76% 1 274 236
  Moyenne 4 370 92,23% 374 69

Lorsqu'on se focalise sur la qualité plutôt de la vitesse, TSP, CMMI 5 et RUP sont premiers suivi de XP. La qualité n'est pas le point fort de l'agilité qui n'arrive qu'en huitième place. Le manque de mesure de la qualité des méthodes agiles et le non usage des revues auront également un impact dans la prochaine comparaison.

Économies: Coût total de propriété (TCO) et coût de la qualité (COQ)

Certaines méthodes plus récentes telles qu'agile et XP n'ont pas été utilisées assez longtemps pour montrer des résultat sur plus de 10 ans. Dans cet article le TCO est limité à cinq ans d'utilisation puisque les données au-delà de cela n'existent pour agile.

Les nombres pour le TCO incluent le temps de développement, cinq ans de maintenance et de réparation de défauts ainsi que 5 ans de support. Pour les fins de cet article, tous ces nombres sont regroupés même si l'outil Software Risk Master les calcule séparément.

Les nombres pour COQ comprennent tous les coûts directs associés à la recherche et à la réparation des défauts depuis le début de la période d'analyse jusqu'à cinq ans d'utilisation du logiciel.

Tableau 3 : Coût total de propriété (TCO) et Coût de la qualité (COQ)

  Méthodes TCO COQ Pourcentage
1 TSP $1 026 660 $298 699 29,09%
2 CMMI 5/Spiral $1 034 300 $377 880 36,53%
3 Extreme (XP) $1 318 539 $627 106 46,56%
4 RUP $1 360 857 $506 199 37,20%
5 Agile/Scrum $1 467 957 $774 142 52,97%
6 OO $1 617 839 $735 388 45,45%
7 CMMI 3/itératif $1 748 043 $925 929 52,97%
8 Binôme/itératif $2 107 861 $756 467 35,89%
9 Preuves/Waterfall $2 216 167 $863 929 38,98%
10 CMMI 1/Waterfall $3 944 159 $2 804 224 71,10%
  Moyenne $1 784 238 $866 996 44,75%

Puisque les applications développées avec les méthodes TSP, CMMI 5 et RUP sont déployées avec peu de défauts, il est assez facile de les améliorer, de les maintenir ou de les supporter. Il s'ensuit que le coût total de propriété après 5 ans favorise clairement les méthodes focalisant la qualité par rapport aux méthodes favorisant la rapidité.

Avec un coût de la qualité de plus de 50%, les méthodes agiles, quoique pas mauvaises en soi, ont intérêt à s'occuper de la qualité plus sérieusement.

Les pourcentages de coût de la qualité révèle un problème chronique du développement logiciel. Il y a tellement de défauts que leur coût de gestion et de résolution occupe la plus grande part dans le coût de développement ou le coût total de propriété.

Les méthodes les plus performantes selon la catégorie

En continuant avec la métaphore des aveugles et le l'éléphant, voici le tableau des meilleures méthodes dans chaque catégorie :

Tableau 4 : Les méthodes les plus performantes dans les 10 catégories

Catégorie Meilleure Méthode
1. Délai de développement eXtreme Programming (XP)
2. Affectation au développement Agile/Scrum (ex aequo)
3. Effort de développement CMMI 5 / spiral
4. Coûts de développement CMMI 5 / spiral
5. Potentiel de défauts TSP
6. Efficacité de la réparation de défaut TSP
7. Défauts livrés TSP
8. Défauts majeurs TSP
9. Coût total de propriété (TCO) TSP
10. Coût de la qualité (COQ) TSP

Le dicton "soyez prudent avec les vœux que vous formulez" semble s'appliquer lorsqu'on regarde ces comparaisons. Les méthodes telles qu'agile qui focalisent sur la rapidité sont très rapides. Les méthodes telles que TSP, RUP et CMMI 5 qui se focalisent sur la qualité ont très peu de défauts :

Pourquoi certaines méthodes ont de moins bons scores côté rapidité, qualité ou économie

Tel qu'on a vu, les différentes méthodes obtiennent des résultats variés côté rapidité, qualité et économie. Toutefois trois méthodes sont arrivées parmi les dernières dans les trois catégories. Ces retardataires sont le waterfall, bonne dernière, les preuves d'adéquation et la programmation en binôme. Il peut être utile d'expliquer la raison probable de ces mauvais scores.

Waterfall et CMMI 1 Ce n'est pas un secret qu'à peu près 35% de projets informatiques des 50 dernières années on été annulés pour cause de mauvaise qualité ou dépassements. La plupart d'entre eux ont utilisé la méthode waterfall et étaient classés CMMI 1 ou n'ont pas utilisé CMMI du tout.

Pour une taille d'environ 1000 point de fonction, la méthode waterfall alloue 25.71% du temps et de l'effort à la recherche et à la réparation de défauts. Le nombre de projets en retard ou qui ont excédé leur budget est d'environ 50%. Ce ne sont pas de grands projets, pourtant avec la méthode waterfall ces projets sont souvent problématiques.

Il faut mentionner que la motivation première des nouvelles méthodes est de maîtriser les problèmes historiques associés au waterfall.

Il y a eu quelques succès obtenus avec la méthode waterfall mais en général ce sont des projets qui ont été réalisé par des équipes d'experts.

Programmation en binôme Malheureusement la programmation en binôme est une erreur coûtant pas mal cher. Le concept des deux personnes prenant chacune son tour les commandes du clavier tandis que l'autre observe ne fonctionne pas en pratique. Les preuves montrent que la programmation en binôme fonctionne mal. Certaines affirmations veulent qu'une paire de développeurs produit un logiciel avec moins de défauts qu'un seul développeur. Malheureusement les développeurs individuels utilisaient des pratiques waterfall. Des programmeurs expérimentés utilisant des outils d'analyse statique et participant à des revues de code formelles produisent un meilleur code pour environ la moitié du coût de la programmation en binôme.

De plus, il y a quelque 90 différentes occupations informatiques. Pourquoi coupler les programmeurs et pas les autres ? Si l'idée de la programmation en binôme fonctionnait tel qu'énoncée, alors les architectes, analystes d'affaire, testeurs, tout le monde devraient être couplés. Pourquoi pas deux chefs de projet au lieu d'un ?

L'usage de la programmation en binôme est symptomatique d'un manque de mesure et aussi un incompréhension de la répartition du talent à l'intérieur de grandes populations. Si une entreprise développait un très grand système avec 500 programmeurs, il ne serait pas possible d'engager 500 programmeurs additionnels pour venir se joindre à eux.

Preuves d'adéquation Le concept de preuves d'adéquation provient du milieu académique et est plus théorique que réalisable. Afin de prouver les algorithmes des logiciels, ceux-ci doivent être exprimés formellement et le personnel faisant les preuves doit posséder une connaissance poussée des mathématiques.

Dans l'échantillon utilisé pour cet article, les 1000 points de fonction contenaient environ 690 exigences spécifiques nécessitant une preuve. C'est la raison pour laquelle même les petites applications prennent du temps avec la méthode des preuves d'adéquation, car faire une preuve consomme beaucoup de temps.

Il serait quasi impossible d'utiliser les preuves d'adéquation avec une application de 10 000 points de fonction, car elle contiendrait 7 406 algorithmes à prouver et cela pourrait prendre plusieurs années durant lesquelles les exigences auraient tellement changé que les preuves initiales ne seraient plus pertinentes.

Associer la bonne méthode aux projets informatiques

Puisque aucune méthode n'arrive première dans toutes les catégories, le lecteur peut bien se demander comment choisir une méthode qui répond aux besoin de son projet.

Pour les petites applications de 1000 points de fonction ou moins et où la rapidité de livraison est le facteur le plus critique, XP, agile et TSP sont de très bons choix.

Pour des application complexes nécessitant une approbation de la FDA, manipulant des systèmes d'armements ou des données financières sensibles, un très haut niveau de qualité est obligatoire. Dans ces cas, TSP, CMMI 5 et RUP sont les meilleurs choix et XP est une alternative possible. Agile a été utilisée pour ce type d'applications mais avec tellement de contorsions que la méthode n'est plus reconnaissable. La qualité n'est pas le point fort d'agile.

Pour les applications pouvant durer plus de 10 ans ou nécessitant des améliorations fréquentes et donc une structure interne bien conçue, TSP est le meilleur choix tandis que CMMI 5 RUP et XP sont de bonnes alternatives. Agile n'a pas eu de succès eu égard à la maintenance et à l'amélioration sur le long terme.

Sommaire et conclusions

Au moment de l'écriture de cet article, l'industrie du développement logiciel compte environ 55 méthodes de développement logiciel différentes. Cela est beaucoup trop important pour une comparaison dans un court article.

En ce qui concerne les 10 méthodes comparées ici, la plupart ont eu des succès et la plupart ont eu des échecs également.

Globalement, la famille agile et les méthodes mettant l'emphase sur la rapidité ont atteint leur but et sont assez rapides.

Les méthodes mettant l'emphase sur la qualité telles que TSP, RUP et CMMI 5 ont également atteint leur but en livrant très peu de défauts.

Aucune méthode ne semble être la panacée qui obtient du succès pour toutes les grandeurs et types d'application.

Cet article tente de montrer les méthodes qui conviennent le mieux selon trois critères importants :

  1. Rapidité
  2. Qualité
  3. viabilité économique à long terme

À propos de l'auteur

Capers Jones est actuellement vice-président et directeur de la technologie de Namcook Analytics LLC. Cette entreprise conçoit des outils de pointe d'estimation et de mesure du risque, du coût et de la qualité. Il a été président de Capers Jones & Associates LLC jusqu'en 2012, un chercheur et gestionnaire chez IBM durant 12 années et l'assistant directeur du développement à ITT Corporation où il a débuté leur programme de mesure de logiciel. Capers est un auteur et conférencier international reconnu. Certains de ses livres sont : "The Economics of Software Quality" (co-auteur Olivier Bonsignour), "Software Engineering Best Practices", "Applied Software Measurement and Estimating Software Costs". Il se penche actuellement sur son 15ème livre ayant pour titre "The Technical and Social History of Software Engineering", qui sera publié à l'automne 2013.

Capers et ses collègues ont accumulé au fil des années des données qui sont utilisées pour évaluer l'efficacité des méthodes d'amélioration des processus informatiques et également pour calibrer la précision des estimations, qui sont citées dans des litiges en matière de logiciel où la qualité, la productivité et les délais font partie des procédures. Il a également travaillé comme un témoin expert lors de 15 procès impliquant des questions de rupture de contrat et de fiscalité logicielle.

 

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT