Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Chapitre 4 Les modèles de développement Comme pour toutes les fabrications, il

Chapitre 4 Les modèles de développement Comme pour toutes les fabrications, il est important d’avoir un processus bien déﬁni et documenté. Dans le cas du logiciel, il s’agit d’un type de fabrication un peu particulier, en un seul exemplaire, car la production en série est triviale par simple recopie. Ce processus de fabrication du logiciel, dont les principales déclinaisons vont être détaillées dans les paragraphes qui suivent, est toujours accompagné d’un processus de gestion de projet (estimation, planiﬁcation, suivi, etc.) et d’un processus qualité (mesure, contrôle qualité, documentation, etc.). Les modèles de développement ou modèles de cycle de vie décrivent à un niveau très abstrait et idéalisé les différentes manières d’organiser la production du logiciel. Les étapes, leur ordonnancement, et parfois les critères pour passer d’une étape à une autre sont explicités : critères de terminaison d’une étape, critères de choix de l’étape suivante, critères de démarrage d’une étape. 4.1 LES MODÈLES LINÉAIRES On peut considérer le « développement sauvage » (cow boy programming) ou « coder et corriger » (code and ﬁx) comme la situation qui prévalait au début de l’informatique, quand la codiﬁcation commençait sans aucun travail d’analyse et de conception préalable. Cela peut encore se concevoir pour de très petits programmes mais certainement pas pour des développements sérieux. Les modèles linéaires sont apparus ensuite. 58 Partie 1. Le développement logiciel 4.1.1. La cascade (waterfall) Dans cette approche proposée en 1970 par Winston Royce [Roy70] et héritée des méthodes classiques d’ingénierie, chaque étape doit être terminée avant que ne commence la suivante. À chaque étape, il y a production d’un « livrable » (deliverable) qui sert de base pour l’étape suivante. La découverte d’une erreur entraîne le retour à la phase à l’origine de l’erreur et une nouvelle cascade avec de nouveaux livrables. Les coûts de correction des erreurs sont donc importants. Il faut si possible « tout bien faire » dès le début. La résolution de beaucoup de facteurs de risque, comme le démarrage du codage ou l’intégration des éléments de l’application (en un unique big bang), sont repoussés à la ﬁn du processus. Cette approche peut donc donner une fausse impression de progression. Les choix en amont sont cruciaux, ce qui est typique d’une production industrielle. Les utilisateurs interviennent en début de processus, pour déﬁnir les besoins, et en toute ﬁn du processus pour valider le système au regard des besoins exprimés au début. FIGURE 4.1 Le modèle de la cascade Par contre, l’approche est simple à comprendre et à utiliser. Elle facilite l’organisation du travail et des équipes dans les grands projets, en proposant des moments clés où des revues peuvent prendre place. Elle simpliﬁe la gestion du projet et l’assurance qualité. Cette approche est peu adaptée si les besoins du client sont changeants ou difﬁciles à déterminer au départ. Elle reste utilisée pour de gros projets, dans des domaines et avec des technologies bien connus et maîtrisés par les équipes de développement. Elle convient également pour la construction d’une nouvelle version d’un logiciel existant ou son portage vers une nouvelle plateforme. 4 • Les modèles de développement 59 4.1.2. Le modèle en V Il s’agit d’une variante du modèle de la cascade qui met en évidence la complémentarité des phases menant à la réalisation et des phases de test permettant de la valider. Les tests sont préparés tout au long des phases menant à la réalisation et exécutés en ﬁn de processus. Le modèle en V, calqué sur la production industrielle classique, met clairement en évidence les différents niveaux de test : – test unitaire : test de chaque composant de l’application pris isolément, – test d’intégration : test des interactions entre les composants de l’application, – test de validation (test système) : validation par les développeurs du système complet par rapport à son cahier des charges, – test d’acceptation (recette) : validation par le client du système complet par rapport aux besoins des utilisateurs. FIGURE 4.2 Le modèle en V Les inconvénients sont similaires à ceux évoqués pour la cascade. Les avantages reconnus sont de placer la vériﬁcation et la validation au centre des préoccupations dès les premiers stades du développement et d’imposer l’idée de livrable évaluable. L’approche convient bien aux projets classiques qui mettent la ﬁabilité au cœur de leurs préoccupations. 4.1.3. Le modèle en Y Il s’agit d’une autre variante du modèle de la cascade qui distingue initialement une branche fonctionnelle et une branche technique aﬁn de paralléliser la résolution des questions correspondantes [RV04]. Le modèle en Y est adapté aux projets technologiquement innovants car il permet de lever au plus tôt les incertitudes liées aux technologies à mettre en œuvre. 60 Partie 1. Le développement logiciel FIGURE 4.3 Le modèle en Y 4.1.4. Discussion Toutes les approches linéaires supposent qu’il est possible de spéciﬁer correctement et exhaustivement les besoins en début de processus et que ces besoins restent stables tout au long du processus de développement. Les erreurs d’analyse, de conception ou de codage sont découvertes tardivement au terme d’un long processus (« effet tunnel »). Il existe en outre des risques de « paralysie par l’analyse », car potentiellement une analyse n’est jamais ﬁnie, de démotivation à cause de la durée et d’effet « big bang », c’est-à-dire de résolution en une fois et très tardivement des principaux risques. 4.2 LES MODÈLES CENTRÉS SUR DES PROTOTYPES L’approche habituelle, qualiﬁée de « prototypage rapide », s’appuie sur le développement rapide d’un prototype avec le client pour analyser ses besoins. Le client donne son feedback qui conduit à des adaptations successives du prototype. Le développement du logiciel ﬁnal se fait ensuite de manière classique, à partir du cahier des charges qui reprend les besoins mis en évidence via le prototype (cf. ﬁgure 4.5). L’idée est de permettre la validation des spéciﬁcations par expérimentation : « Je saurai ce que je veux lorsque je le verrai ! ». Cette approche permet une validation beaucoup plus concrète des besoins, ce qui minimise les risques d’erreurs à ce niveau. Par contre, la planiﬁcation initiale du projet est délicate à faire. 4 • Les modèles de développement 61 FIGURE 4.4 Le prototypage rapide On peut également utiliser des prototypes ultérieurement dans le processus de développement. Par exemple, au niveau de la conception, pour s’assurer de la faisabilité de parties critiques ou valider des options de conception. On parle alors de « prototypage expérimental ». Enﬁn, on peut construire un prototype comme embryon du futur système. Contrairement aux cas précédents le prototype n’est plus jeté mais réutilisé. Ce genre de démarche est à rapprocher du développement itératif et incrémental. 4.3 LES MODÈLES ITÉRATIFS ET INCRÉMENTAUX 4.3.1. Déﬁnition Dans ces approches le logiciel est développé en plusieurs itérations. Cela revient à répéter des mini-processus de développement, plus ou moins complets. Chaque itération correspond au rafﬁnement d’un développement précédent ou à l’ajout d’un incrément supplémentaire (d’où l’expression « itératif et incrémental »). C’est intéressant pour les projets de grande taille, car on peut obtenir rapidement un logiciel fonctionnel offrant les fonctionnalités de base. Dans l’approche la plus classique, le logiciel est spéciﬁé et conçu dans son ensemble. C’est la conception détaillée et la réalisation (codage, tests unitaires, intégration à ce qui a déjà été développé, livraison) qui se font par itérations successives (cf. ﬁgure 4.5). Les avantages sont de permettre de développer en premier les fonctions primordiales ou les plus risquées. Les clients peuvent réagir après chaque itération. On peut aussi obtenir une meilleure motivation de l’équipe de développement qui voit se concrétiser plus rapidement ses efforts. Les autres difﬁcultés, comme la nécessité de recueillir dès le départ et de ﬁger les besoins, demeurent. Dans d’autres approches, les itérations incluent l’analyse et la spéciﬁcation des besoins, ce qui exclut la possibilité d’une conception globale a priori (cf. ﬁgure 4.6). Les avantages principaux sont d’avoir un recueil des besoins continu et évolutif, une détection précoce des erreurs, une implication continue des clients/utilisateurs. Les inconvénients majeurs sont liés à la difﬁculté de gérer les besoins (« explosion des besoins ») et à la difﬁculté de déﬁnir les incréments. Une direction rigoureuse est nécessaire pour ne pas retomber dans les errements du code and ﬁx. 62 Partie 1. Le développement logiciel FIGURE 4.5 Une approche itérative à partir d’une conception préalable FIGURE 4.6 Une approche complètement itérative 4.3.2. Le modèle en spirale Le modèle en spirale de Barry Boehm (1988) et le processus uniﬁé de James Rumbaugh, Ivar Jacobson et Grady Booch (1999) sont des cas particuliers d’approches itératives. Le chapitre suivant revient en détail sur le processus uniﬁé qui correspond à l’état de l’art en développement objet utilisant UML. Le modèle en spirale est parfois qualiﬁé de « méta procédé » car il peut inclure une activité de choix du procédé de développement. Il met l’accent sur l’identiﬁcation et la résolution des risques : 4 • Les modèles de développement 63 – humains, comme le manque de compétences, d’expérience, de communication, de motivation, etc., – organisationnels, comme le manque de temps, de budget, la non-disponibilité de composants externes, etc., – uploads/Industriel/ chapitre-iv-ingenierie-logiciel.pdf