ENIS 2010-2011 Le génie logiciel Moez Krichen moez.krichen@gmail.com
Cycle de vie du logiciel Une version d'un logiciel correspond à un état donné de l'évolution d'un produit logiciel utilisant le «versionnage» (versioning) Le versionnage est le mécanisme qui consiste à conserver (et retrouver) la version d'une entité logicielle quelconque même après l'apparition et la mise en place de versions plus récentes Une version de logiciel est le plus souvent associée à une numérotation qui permet de l'identifier, voire dans certains cas à un nom symbolique 2
Cycle de vie du logiciel Pour les logiciels de nature commerciale (progiciels), il pourrait exister deux numérotations : 1. Numérotation interne à l'entreprise 2. Numérotation présentant un caractère commercial Cette séparation permet de séparer l'aspect marketing et/ou contractuel de l'aspect technique (nombreuses versions) Exemple : le traitement de texte Word existe en version Word 2000 (version commerciale), ce qui correspond à la version 9.0.2812 (version technique) 3
Cycle de vie du logiciel Gestion de l'évolution d'un logiciel : La gestion de l'ensemble des versions d'un logiciel et de celles de ses différents éléments requiert l'utilisation d'un système de gestion de versions (exemple : svn) Un système de gestion de versions permet l'existence simultanée de plusieurs versions du logiciel, en développement ou en maintenance Différentes branches permettent d'introduire des modifications, d'en comparer les versions et d'en fusionner les changements 4
Cycle de vie du logiciel Gestion de l'évolution d'un logiciel : Une application peut être développée en plusieurs branches indépendantes Il existe généralement la branche stable et la branche de développement, chaque branche ayant sa propre version 5
Cycle de vie du logiciel Types d'évolutions : Il pourrait exister des évolutions mineures et/ou des évolutions majeures d'un logiciel Les évolutions majeures apportent de nouvelles fonctionnalités, voire restructurent complètement l'application Les évolutions mineures apportent principalement des corrections de bugs ou des ajouts de fonctionnalités secondaires (exemple: ajout d'un bouton de raccourci) 6
Cycle de vie du logiciel Numérotation des versions : Il n'y a pas qu'une seule façon de décrire la version d'un logiciel ; il existe différents systèmes En utilisant un ou plusieurs chiffres pouvant être séparés par des points : 1.4, 0.9.95 En suivant une règle mathématique. Par exemple, la version de TeX tend de manière asymptotique vers π ; la version actuelle est 3.141592. De même, la version de Metafont tend vers e ; la version actuelle est 2.71828 Grâce à l'année de sortie du logiciel: Adobe Illustrator 88 Grâce à la date de sortie: Wine 20040505 (pour la version sortie le 5 mai 2004), Ubuntu 8.04 (pour la version sortie en avril 2008) 7
Cycle de vie du logiciel Numérotation des versions : On parle aussi d'édition pour désigner des évolutions mineures d'une version Dans l'exemple de la version 2.6.10, la version sera 2 et l'édition la 6.10 ou bien la version la 2.6 et l'édition 10 (tout dépend des habitudes de l'éditeur ou de la communauté de développement) Outre la numérotation qui permet d'identifier une version précise, il est courant de qualifier certaines versions afin de préciser à quel cycle de développement du logiciel on est. Par exemple, Mac OS 10.5 est surnommé Leopard. Le dernier numéro peut être remplacé par une lettre, au lieu de 2.5.21 on aurait 2.5.U (c'est le cas notamment pour de nombreux éditeurs de jeux vidéo) 8
Forme Générale : Cycle de vie du logiciel Généralement, un numéro de version est composé d'une suite de nombres séparés par des points Les nombres sont ordonnés du plus significatif au moins significatif : une évolution du premier nombre correspond à une refonte (relative) du logiciel, tandis que le dernier correspond à une évolution mineure Ainsi, une version nommée «2.5.21» pourrait avoir le sens suivant: - 2ème version publiée - 5ème ajout de fonctionnalité dans la version 2-21ème révision de la version 2.5 9
Forme Générale : Cycle de vie du logiciel De manière générale plus les modifications apportées par le nouveau patch ou la nouvelle version sont importantes plus le numéro qui changera sera à gauche S'il s'agit d'une simple correction d'un bug mineur on passera de 2.5.21 à 2.5.22 Par contre si on a le droit à une mise à jour majeure (de nouvelles fonctionnalités, un gameplay différent, etc.) on passera de 2.5.21 à 2.6.0 10
Forme Générale : Cycle de vie du logiciel Traditionnellement, la première version fonctionnelle d'un logiciel est notée 1.0. Certaines versions de logiciels sont notées 0.x ou 0.x.x, indiquant que le logiciel n'est pas abouti et correspond généralement à une version bêta Exemple : la version 2.6.10 du noyau Linux indique la 11ème révision (la numérotation commence par 0) de la 4ème version mineure (les numéros impairs ne sont pas utilisés pour les versions stables) de la 2ème version majeure du noyau. Lorsqu'un numéro de version est composé de trois nombres, ils sont respectivement appelés : majeur, mineur et micro (en anglais major, minor, micro) 11
Exemple d'arbre des versions d'un logiciel 12
Cycle de vie du logiciel Phases de développement : Un prototype est un premier jet de l'application, ne disposant que de peu - voire pas - de réelles fonctionnalités, et permettant d'avoir un aperçu visuel de l'objectif recherché (on parle également de maquette) Version avancée se dit d'un logiciel qui est en cours de développement Ce terme permet de différencier la version en évolution d'un logiciel, qui est encore à un stade entre alpha et RC, de sa version stable Ainsi vous pouvez choisir entre un logiciel donné en version stable 1.0 par exemple, et sa version avancée 1.1 (son utilisation est déconseillée à moins d'avoir absolument besoin des nouvelles fonctionnalités qui ne sont pas dans la version stable ou dans le but de tests) 13
Les phases de développement d'un logiciel 14
Cycle de vie du logiciel Version alpha : Une version alpha n'est pas censée être accessible à un large public : c'est une version interne Généralement, un produit en test alpha (en anglais alpha-test) n'a pas toutes les fonctionnalités prévues dans le produit final L'alpha est donc dépourvue de certaines fonctionnalités, et contient un nombre de bugs encore important Cette phase est traitée à l'intérieur même du studio de développement 15
Cycle de vie du logiciel Version bêta : Le test bêta (en anglais beta-test) est la deuxième période d'essai d'un produit informatique avant sa publication Un produit en période de test bêta est généralement soumis à un nombre important ou représentatif de personnes: les bêta-testeurs Les bêta-testeurs peuvent être soit des employés de la société qui développe le logiciel, soit des bénévoles notamment dans le cas des logiciels libres Ces personnes ont pour but d'utiliser le logiciel et de rapporter les problèmes rencontrés ainsi que leurs suggestions 16
Cycle de vie du logiciel Il existe deux formes de test bêta : 1. Bêta ouverte ou bêta publique, dans laquelle n'importe qui peut participer, avec parfois une restriction technique (nombre d'utilisateurs connectés simultanément, etc.) 2. Bêta fermée ou bêta privée, dans laquelle les personnes intéressées par le produit doivent s'inscrire au préalable ou sont contactées par les fabricants du produit testé qui sélectionne les candidatures 17
Cycle de vie du logiciel Version admissible ou pre-release : Une version admissible est une version du logiciel qui correspond, du côté pratique, à la version «finale» ou «stable» du dit logiciel Elle est mise à disposition à des fins de «tests de dernière minute» visant à déceler les toutes dernières erreurs subsistant au sein du programme Le terme anglais release candidate (RC) est beaucoup plus utilisé 18
Cycle de vie du logiciel Version stable : ( Aussi appelée version finale ou or ou GA, pour General Availability ) Quand un logiciel peut accomplir toutes les tâches prévues, il arrive à sa version «stable» C'est cette version qui est généralement mise sur autre support de publication: CD-ROM, DVD, etc. Bien que finale, on trouve toujours de nouveaux besoins auxquels un logiciel doit s'adapter, en ajoutant de nouvelles fonctionnalités Un nouveau cycle de développement recommence à partir de cette version du logiciel Ces mises à jour sont mises à disposition sous forme de patch, ou sont intégrées à la prochaine version stable du logiciel 19
Les différents modèles de cycle de développement Le modèle en cascade ( Waterfall model ) : Un des premiers modèles qui a été proposé Il date des années 70 Ce modèle est strict et lourd Chaque phase doit être approuvée avant de pouvoir commencer l'autre 20
Modèle en cascade 21
Les différents modèles de cycle de développement Le modèle en cascade : avantages Chaque phase est finie, elle est donc gérable tant au niveau du temps que des ressources Le code est créé assez tardivement, il y a donc une bonne compréhension du système 22
Les différents modèles de cycle de développement Le modèle en cascade : inconvénients Il y a des risques de découvrir des erreurs qu'a la fin et qui nécessiteront de refaire toutes les étapes L'ajout de nouvelle exigence implique qu'il faille refaire toutes les étapes Plus un problème doit être résolu ou un changement doit être fait tard, plus il coûtera cher 23
Les différents modèles de cycle de développement Le modèle en cascade : Ce modèle est encore très utilisé Il a été revu dans sa version initiale Dans la nouvelle version, il est possible de revenir en arrière et des prototypes sont créés à chaque phase Le modèle est ainsi, dans cette nouvelle version, plus près de la réalité 24
Les différents modèles de cycle de développement Le modèle en V : Le modèle du cycle en V a été imaginé pour pallier le problème de réactivité du modèle en cascade Ce modèle est une amélioration du modèle en cascade qui permet en cas d'anomalie, de limiter un retour aux étapes précédentes Le cycle en V est devenu un standard de l'industrie du développement de logiciel et de la gestion de projet depuis les années 1980 25
Modèle en V 26
Les différents modèles de cycle de développement Le modèle en V : Les étapes de la partie montante doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des défauts sont détectés afin d'améliorer le logiciel De plus le cycle en V met en évidence la nécessité d'anticiper et de préparer dans les étapes descendantes les «attendus» des futures étapes montantes Ainsi les attendus des tests de validation sont définis lors des spécifications, les attendus des tests unitaires sont définis lors de la conception, etc. 27
Les différents modèles de cycle de développement Le modèle par incrément : Dans ce modèle, un seul composant est développé à la fois On débute par définir les exigences et on les décompose en sous-système À chaque version du logiciel, de nouvelles fonctionnalités venant combler les exigences sont ajoutées On continue de la sorte jusqu'à ce que toutes les fonctionnalités demandées soient comblées par le système Chaque incrément peut utiliser un autre modèle (v, en cascade...) 28
Modèle par incrément 29
Les différents modèles de cycle de développement Le modèle par incrément : Le développement sont ainsi moins complexe, L'intégration est moins brutale et le client a plus rapidement un système même s'il n'est pas complet Par contre, le cœur du système peut être à revoir lorsqu'on passe à une autre incrémentation du système Il peut ainsi s'avérer complexe d'ajouter certaines fonctionnalités Ce modèle convient au projet de grande envergure L'architecture doit être bien pensée dès le départ afin de réduire les risques par la suite. 30
Les différents modèles de cycle de développement Le modèle itératif : A chaque nouveau besoin, le cycle itératif propose : 1. d'étudier la faisabilité 2. puis d'imaginer son élaboration 3. puis de passer à sa fabrication 4. et enfin à la livraison Contrairement au modèle incrémental, les versions du logiciel ne sont pas planifiées à l avance 31
Les différents modèles de cycle de développement Le modèle itératif : Ce modèle est inspiré de la roue de Deming qui est une approche itérative dont le but est d'améliorer en permanence la qualité Elle se compose de 4 étapes : Plan, Do, Check, Act (PCDA) Plan : ce que l'on prévoit de faire, étude la faisabilité, spécifications Do : on imagine comment on va le réaliser : élaboration, architecture Check : vérification et mesure des risques Act : tests, validation et livraison au client L'idée est de livrer le plutôt possible une version qui puisse être testée par le client 32
Les différents modèles de cycle de développement Le modèle itératif : 33
Les différents modèles de cycle de développement Le modèle en spirale : Ce modèle itératif met l'accent sur l'activité d'analyse des risques Ce modèle est plus récent, il date du milieu des années 80 L'emphase de ce modèle et mise sur la réduction des risques Ce modèle est adapté pour les gros projets complexes Les risques sont sans cesse évalués à chaque cycle 34
Modèle en spirale 35
Les différents modèles de cycle de développement Comparaison des approches Cascade, V et Itératif : Le cycle en V a pour origine l'industrie lourde La particularité de ce milieu est que la phase qui suit nécessite bien plus de ressources que la précédente Par exemple, pour fabriquer un objet en matière plastique : 1. un bureau d'étude va concevoir le produit 2. puis des empreintes de moules seront usinées et placées dans des carcasses pour recevoir de la matière plastique par injection 3. et une fois que le prototype est correct, on passe à une phase de production 36
Les différents modèles de cycle de développement Comparaison des approches Cascade, V et Itératif : Pour un objet simple tel qu'un gobelet en plastique, la conception est une affaire d'une poignée de semaines (soit quelques milliers d'euros) Alors qu'un moule (empreinte + carcasse) nécessite plusieurs mois de fabrication et plusieurs centaines de milliers d'euros Par conséquent, dans un tel contexte, pour bien gérer son projet, il est important de ne pas négliger la validation de chaque étape sous peine de le voir déraper 37
Les différents modèles de cycle de développement Comparaison des approches Cascade, V et Itératif : Ce phénomène intervient sur des chantiers logiciels réunissant des dizaines voire des centaines de personnes Les décisions de l'équipe de direction ou de l'architecte projet impactent tellement d'ingénieurs pour de longues durées qu'il vaut mieux s'assurer de la validité de chaque étape 38
Les différents modèles de cycle de développement Pour limiter l'entropie (désordre) du système constitué par l'équipeprojet, il est nécessaire de formaliser par des documents (voire des outils) : - les processus - les besoins - les spécifications logicielles - l'architecture logicielle - les tests 39
Les différents modèles de cycle de développement Dans le cas d'un projet logiciel impliquant une douzaine de personnes pendant une à deux années, la configuration n'est plus la même Avec de tels projets on dispose : 1. d'une plus grande réactivité, due à : a. une proximité géographique b. une facilité (relative) de communication 2. d'un facteur de coût limité entre chaque étape Aussi, il est possible de s'orienter vers des méthodes de développement dites méthodes agiles en diminuant le formalisme et en multipliant le nombre de cycles (fonctionnement itératif). 40
Les méthodes agiles Les méthodes Agiles sont des groupes de pratiques pouvant s'appliquer à divers types de projets Elles se limitant plutôt actuellement aux projets de développement en informatique (conception de logiciel) Les méthodes Agiles se veulent plus pragmatiques que les méthodes traditionnelles Elles impliquent au maximum le demandeur (client) et permettent une grande réactivité à ses demandes Elles visent la satisfaction réelle du besoin du client et non les termes d'un contrat de développement La notion de méthode agile a été officialisée en 2001 par un document, le Manifeste Agile (Agile Manifesto), signé par 17 personnalités impliquées dans l'évolution du génie logiciel, en particulier, en tant qu'auteurs de leur propre méthode 41
Les méthodes agiles Les méthodes Agiles et les pratiques qu'elles recouvrent seraient antérieures au Manifeste Agile Ce manifeste ne serait donc pas l acte de naissance des méthodes Agiles ou du mouvement Agile, mais la formalisation consensuelle par les auteurs de ces méthodes, toutes nées dans la deuxième partie de la décennie 90 Ces méthodes avaient des valeurs communes, une structure (cycle de développement) commune (itérative, incrémentale et adaptative) et une base de pratiques, soit communes, soit complémentaires Parmi ces méthodes on trouve en premier lieu la méthode RAD (Développement rapide d'applications) de James Martin (1991), puis DSDM la version anglaise du RAD (1995) Plusieurs autres méthodes comme ASD ou FDD reconnaissent leur parenté directe avec RAD Les deux méthodes Agiles les plus connues en France sont : la méthode Scrum (1996) et la méthode XP pour Extreme programming (1999) 42
Les méthodes agiles La notion de méthode agile a émergé avec des pratiques ciblant uniquement le développement d'une application informatique Mais un mouvement managérial plus large (Management Agile) commencerait à coupler les valeurs Agiles aux techniques de l'amélioration continue de la qualité (MTQS ou Lean) 43
Les méthodes agiles Quatre valeurs fondamentales : (entre parenthèse, les citations du manifeste) 1ère valeur - L'équipe («Personnes et interaction plutôt que processus et outils») : Dans l'optique agile, l'équipe est bien plus importante que les outils (structurants ou de contrôle) ou les procédures de fonctionnement Il est préférable d'avoir une équipe soudée et qui communique composée de développeurs (éventuellement à niveaux variables) plutôt qu'une équipe composée d'experts fonctionnant chacun de manière isolée La communication est une notion fondamentale 44
Les méthodes agiles Quatre valeurs fondamentales : (entre parenthèse, les citations du manifeste) 2ème valeur - L'application («Logiciel fonctionnel plutôt que documentation complète») Il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est une aide précieuse mais non un but en soi Une documentation précise est utile comme moyen de communication La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l'équipe 45
Les méthodes agiles Quatre valeurs fondamentales : (entre parenthèse, les citations du manifeste) 3ème valeur - La collaboration («Collaboration avec le client plutôt que négociation de contrat») Le client doit être impliqué dans le développement On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client Le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à ses attentes 46
Les méthodes agiles Quatre valeurs fondamentales : (entre parenthèse, les citations du manifeste) 4ème valeur - L'acceptation du changement («Réagir au changement plutôt que suivre un plan») La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet Les premières releases du logiciel vont souvent provoquer des demandes d'évolution 47
Les méthodes agiles Principes : ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles 1. «Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles» 2. «Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client» 3. «Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte» 4. «Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet» 48
Les méthodes agiles Principes : ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles 5. «Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail» 6. «La méthode la plus efficace pour transmettre l'information est une conversation en face à face» 7. «Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet» 8. «Les processus agiles promeuvent un rythme de développement durable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment» 49
Les méthodes agiles Principes : ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles 9. «Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité» 10. «La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle» 11. «Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent» 12. «À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens» 50
Les méthodes agiles Tronc des pratiques communes des méthodes Agiles : 1. Les pratiques communes liées aux ressources humaines - Participation de l utilisateur final aux groupes de travail - Groupes de travail disposant du pouvoir de décision - Autonomie et organisation centralisée de l équipe (motivation) - Spécification et validation permanente des Exigences 51
Les méthodes agiles Tronc des pratiques communes des méthodes Agiles : 2. Les pratiques communes liées au pilotage du projet - Niveau méthodologique variable en fonction des enjeux du projet - Pilotage par les enjeux et les risques - Planification stratégique globale basée sur des itérations rapides - Réalisation en jalons par prototypage actif, itératif et incrémental - Recherche continue d amélioration des pratiques 52
Les méthodes agiles Tronc des pratiques communes des méthodes Agiles : 3. Les pratiques communes liées à la qualité de la production - Recherche d excellence technique de la conception - Vision graphique d une modélisation nécessaire et suffisante - Vision de la documentation nécessaire et suffisante - Normes et techniques raisonnables de qualité du code (métrique) - Architecture à base de composants - Gestion des changements automatisée 53
Les méthodes agiles Critères d'éligibilité : De multiples facteurs contextuels peuvent être pris en considération pour valider ou invalider la possibilité d'application d'une méthode agile 1. Favorisant : - Besoin rapide de mise à disposition du produit - Imprévisibilité des besoins du client - Nécessité de changements fréquents - Besoin de visibilité du client sur l'avancement des développements - Présence de l'utilisateur assurant un feedback immédiat 54
Les méthodes agiles Critères d'éligibilité : De multiples facteurs contextuels peuvent être pris en considération pour valider ou invalider la possibilité d'application d'une méthode agile 2. Défavorisant : - Indisponibilité du client ou de l'utilisateur - Dispersion géographique des ressources humaines - Inertie des acteurs du projet ou refus des changements 55
Les méthodes agiles Critiques : Dans les cas ou les critères d'éligibilité de l'utilisation d'une approche agile n'ont pas été respectés, la méthode peut montrer plusieurs limites: - Risques de dérives - Documentation insuffisante - Inadaptation à des projets de grande envergure 56
Exercices 1. Par quoi se distingue la méthode XP des autres méthodes agiles? 2. Le RUP fait-il partie des méthodes agiles? 3. En quoi consiste le «Test Driven Development»? 57
XP - Extreme Programming La méthode XP (extreme programming) est très axée sur la partie Construction de l'application Une de ses originalités réside dans l approche de planification qui se matérialise sous la forme d un jeu intitulé «Planning game» et qui implique simultanément les utilisateurs et les développeurs 58
XP - Extreme Programming La méthode XP (extreme programming) est très axée sur la partie Construction de l'application Une de ses originalités réside dans l approche de planification qui se matérialise sous la forme d un jeu intitulé «Planning game» et qui implique simultanément les utilisateurs et les développeurs 59
XP - Extreme Programming On y notera aussi des techniques particulières liées à la production du code comme : 1. La programmation en binôme (Pair programming) 2. L'appropriation collective du code 3. La refactorisation (refactoring) (Amélioration régulière de la qualité du code sans en modifier le comportement. On retravaille le code pour repartir sur de meilleures bases tout en gardant les mêmes fonctionnalités. Les phases de refactoring n'apportent rien au client mais permettent aux développeurs d'avancer dans de meilleures conditions et donc plus vite.) 4. L'intégration continue 60
RUP - Rational Unified Process Processus unifié (PU) est une méthode de prise en charge du cycle de vie d un logiciel et donc du développement, pour les logiciels orientés objets C est une méthode générique, itérative et incrémentale, contrairement à la méthode séquentielle Merise (ou SADT) PU vient compléter la systémique des modèles UML Elle est le résultat final d une évolution de l approche d Ericsson qui est au fondement d une des premières méthodes de développement pour applications orientées objets, la méthode Objectory Process (1987) Objectory Process (version 1 à 3.8 en 1995) a elle-même servi de base à la société Rational pour la création de Rational Objectory Process (1997) (version 4.1), parente direct de RUP en 1998 61
RUP - Rational Unified Process RUP (Rational Unified Process) n'est pas une méthode Agile, c'est un produit propriété d'ibm Il en existe une déclinaison Agile, mais non libre, sous l'acronyme de AUP (Agile Unified Process) RUP se caractérise par une approche globale nommée «Vue 4+1» (vue ayant fortement inspiré UML) Les 5 composants de cette vue sont : la vue des Cas d'utilisation, la vue Logique, la vue d'implémentation, la vue du Processus, la vue du Déploiement RUP offre aussi, à l'identique du RAD 2, un processus guide formel et adaptable comme guide d'activité 62
TDD - Test Driven Development En français, Développement Piloté par les Tests Le cycle préconisé par TDD comporte cinq étapes : 1. écrire un premier test 2. vérifier qu'il échoue (car le code qu'il teste n'existe pas), afin de vérifier que le test est valide 3. écrire juste le code suffisant pour passer le test 4. vérifier que le test passe 5. puis refactoriser le code, c'est-à-dire l'améliorer tout en gardant les mêmes fonctionnalités 63
TDD - Test Driven Development Intérêt : Ces tests permettent aussi de préciser les spécifications du code, et donc son comportement ultérieur en fonction des situations auxquelles il sera exposé Ceci facilite la production d'un code valide en toutes circonstances et on obtient donc un code plus juste et plus fiable. En écrivant les tests d'abord, on utilise le programme avant même qu'il existe et On s'assure ainsi que le code produit est testable unitairement Il est donc impératif d'avoir une vision précise de la manière dont on va utiliser le programme avant même d'envisager son implémentation Cela évite souvent des erreurs de conception dues à une précipitation dans l'implémentation avant d'avoir défini les objectifs 64
TDD - Test Driven Development Intérêt : De plus, le fait d'avoir des tests augmente la confiance en soi du programmeur lors de la refactorisation du code : il sait qu'à un moment donné les tests ont réussi Il peut ainsi se permettre des changements radicaux de design en étant sûr, à la fin, d'avoir un programme se comportant toujours de la même façon (si les tests réussissent toujours) L'utilisation de TDD permet la construction conjointe du programme et d'une suite de tests de non-régression L'utilisation de TDD permet en outre d'estimer de manière plus précise l'état d'avancement du développement d'un projet 65