Introduction Génie Logiciel Cours 1.2 Processus de développement Cycles de Vie

Introduction Génie Logiciel Cours 1.2 Processus de développement Cycles de Vie 1ère année second cycle Septembre 2017 AMAR BENSABER Djamel 2 Plan „ Introduction „ Modèles en cascade „ Modèles évolutifs „ Modèle en spirale „ Modèles agiles „ Synthèse 3 Rappel sur les activités „ Le développement comprend un ensemble d’activités „ La gestion des exigences „ La spécification „ La conception „ L’implantation „ La validation „ L’intégration „ Le déploiement „ La maintenance „ L’enchaînement de ces activités se fait plus ou moins bien 4 Cycle de vie du logiciel / Processus de développement „ Un processus de développement définit un ensemble d’activités et leur enchaînement „ Une activité comprend „ des tâches, „ des contraintes, „ des ressources, „ une façon d’être réalisée „ La plupart des modèles des processus reprennent les activités fondamentales mais les organisent différemment „ De nombreux modèles ont été définis „ Un modèle peut être spécifique à une organisation et à un type de logiciels (ex: embarqué) „ Il existe malheureusement peu d’outils supportant les processus 5 Plan „ Introduction „ Modèles en cascade „ Modèles itératifs „ Autres modèles „ Modèles agiles „ Synthèse 6 Modèles en cascade Principes „ Considérer le développement logiciel comme une succession d’étapes réalisées de façon strictement séquentielle „ Chaque étape correspond à une activité de base „ Chaque étape est validée „ Il n’y a pas (ou peu) de retours en arrière 8 Modèles en cascade « Waterfall model » (1970) „ Définition d’un ensemble plus large et plus complet d’activités „ Chaque activité est validée par un document „ Pas (ou peu) de retours arrière „ Inspiré des processus d’ingénierie 9 Modèles en cascade « Waterfall model » avec itération „ Introduction des retours en arrière (limité à la phase précédente) „ Plus flexible mais lourd à gérer „ Nombre d’itération limité 10 Modèles en cascade Le cycle de vie en V „ Structuration de la phase de validation „ Les tests sont définis à l’issue de chaque phase 11 Modèles en cascade Avantages „ Simple et facile à comprendre „ Force la documentation : une phase ne peut se terminer avant q’un document soit validé „ Le test est inhérent à chaque phase „ Les progrès sont tangibles (pour l’équipe de développement) 12 Modèles en cascade Limites „ Modèle dirigé par les documents „ Non compréhensibles par les clients „ Le produit final est la première chose que voit le client „ Est-ce un vraiment problème ? „ Fait l’hypothèse de la faisabilité „ Ne marche que si les exigences sont stables et le problème connu „ Manque de flexibilité (ne traite pas les évolutions, notamment des exigences) „ Problèmes découverts en phase de validation „ Irréaliste dans de nombreux cas 13 Modèles en cascade Conclusions „ Conditions d’utilisation „ Seulement quand les exigences sont bien connues et non sujettes à modification „ Fonctionnalités / Attentes utilisateurs „ Technologies utilisées „ Encore assez populaires „ Simples et similaires au modèles utilisés dans d’autres disciplines „ Souvent utilisés par les non spécialistes 14 Plan „ Introduction „ Modèles en cascade „ Modèles incrémentaux „ Modèle en spirale „ Modèles agiles „ Synthèse 15 La nature changeante d’un projet 1 : Le changement est inévitable „ L’environnement technique et économique évolue „ Les besoins et les souhaits des clients changent „ Les priorités du management aussi Î les méthodes en cascade ne marchent pas 2 : On ne peut pas attendre de tout savoir pour commencer „ Réduction impérative du time-to-market „ Illusion de la perfection 16 Définition des exigences min et des incréments Conception de l’architecture ou d’un noyau Développement d’un incrément Intégration et validation Produit final Modèles incrémentaux Principes „ Diviser le projet en incréments „ Un incrément = une sous partie fonctionnelle cohérente du produit final „ Chaque incrément ajoute de nouvelles fonctions „ Chaque incrément est testé comme un produit final „ Les incréments sont définis a priori (classification des exigences – par le client si possible) 17 Modèle incrémental - 1 „ Architecture évolutive „ La première version constitue le noyau „ Les versions suivantes s’appuient sur l’existant et étendent l’architecture „ Chaque version donne lieu à un cycle de vie complet Modèle incrémental - 2 Architecture stable La première version fournit une enveloppe Complète Chaque nouvelle version fournit un ou plusieurs sous système en respectant l’architecture Le développement en parallèle est possible (surtout pour les incréments) 18 Modèles incrémentaux Avantages Une première version du système est fournie rapidement ROI rapide (Retour sur investissement) Réduit le stress du management ! En général, cette version n’est pas mise en production Les risques d’échec sont diminués Découverte des problèmes assez tôt Les parties importantes sont fournies en premier et seront donc testées plus longuement Les clients peuvent ajouter des exigences à tous moments 19 20 Modèles incrémentaux Limites „ Les incréments „ Difficile à définir : mapper des exigences sur des incréments est complexe „ Trop peu d’incréments Æ on se rapproche du modèle en cascade „ Trop d’incréments Æ ingérable „ L’architecture „ Difficile de concevoir une architecture stable dès le début ou facilement évolutive „ Difficile d’identifier des services techniques communs „ Ne traite pas toutes les évolutions, notamment celles qui remettent en cause l’architecture 21 Implementation, integration Deliver to client Design Specifications Build 1: Implementation, integration Deliver to client Design Specifications Build 2: Implementation, integration Deliver to client Design Specifications Build 3: … … … specification team design team implementation/integration team Implementation, integration Deliver to client Design Specifications Build n: Plus flexible Pas de conception globale Æ Pb de réutilisation des incréments Autre modèle incrémental 22 Prototypage „ Construire un prototype jetable pour mieux comprendre les points durs (exigences, technologies) Définition des objectifs Plan de prototypage Plan de prototypage Définition des fonctionnalités Développement du prototype Évaluation du prototype Spécification (légère) Spécification (légère) Prototype Prototype Rapport d’évaluation Rapport d’évaluation Propriétés du prototypage Avantages Permet d’impliquer l’utilisateur et d’éclaircir les zones troubles Permet d ’évaluer des risques et de tester une solution Utile dans tous les cycles de vie Il existe des outils de maquettage/prototypage Limites Le client doit comprendre ce qui est propre au prototype Coût mal compris par les managers et les clients Tentation de construire à partir du prototype et donc d’utiliser des solutions non optimales N’aborde qu’une phase du développement. 23 24 Plan „ Introduction „ Modèles en cascade „ Modèles évolutifs „ Modèle en spirale „ Modèles agiles „ Synthèse 25 Modèle en spirale (Boehm, 1988) „ Le cycle de vie est représenté à l’aide d’une spirale „ Chaque boucle représente une phase du développement „ La boucle la plus interne traite des premières phases (faisabilité). La plus externe traite de la livraison „ Chaque boucle traverse quatre sections : „ Définition des objectifs de la phase (la boucle) „ Evaluation des risques et plan de gestion „ Développement et validation „ Planification de la phase suivante „ Nombre de cycles variable 26 Modèle en spirale : schéma 27 Principe du modèle en spirale „ Reconnaissance explicite de la notion de risque „ Exemples „ défaillance de personnel „ calendrier et budgets irréalistes „ développement de fonctionnalités inappropriées „ développement d’interfaces utilisateurs inappropriées „ produit « plaqué or » (non rentable) „ volatilité des besoins „ problème de performances „ exigences démesurées par rapport à la technologie „ tâches ou composants externes défaillants 28 Attention „ Le modèle en spirale est en fait un méta- modèle „ Il offre un cadre où chaque boucle doit être instanciée „ On peut par exemple créer „ Une boucle de faisabilité „ Une boucle de prototypage „ Des boucles de développement itératif, etc. „ Il faut alors trouver le bon modèle de processus pour chaque boucle ! 29 Exemple „ Rapide cahier des charges „ Un logiciel pour gérer les emprunts de documents dans une nouvelle bibliothèque très moderne qui possèdera des ouvrages de toutes natures (dont multimédia) „ Le logiciel devra permettre la visualisation, l’emprunt, le téléchargement et la réservation des ouvrages. „ Le logiciel devra utiliser les dernières avances des NTICs (Nouvelles Technologies de l’Information et de la Communication) „ Les futurs utilisateurs sont très motivés mais ne savent pas exactement à quoi s’attendre (ils ne connaissent pas les NTICs) 30 Problèmes „ Difficultés liées à ce projet „ C’est un produit nouveau „ On ne peut pas se baser sur un produit existant „ Nouveaux types de documents „ Nouveaux types de consultation (téléchargement) „ Utilisation de technologies nouvelles est immatures „ Besoins client à affiner 31 Approche retenue „ Approche itérative avec 5 incréments (ou boucles) „ Incrément 1 : étude de faisabilité „ Incrément 2 : prototypage „ Incrément 3 : fonctions de visualisation „ Incrément 4 : fonctions d’emprunt et de téléchargement „ Incrément 5 : fonctions de réservation 32 Premier incrément „ Objectifs „ Étude de faisabilité „ Focalisation sur la technologie Æ ce n’est pas un prototype „ Trouver les alternatives technologiques si problème „ Identification des risques „ Connaissances uploads/Industriel/ cours-1-2-cyclesdevie-2.pdf

Tags
Industrielmodèles développement cascade modèle incrément
Documents similaires
  • 20
  • 0
  • 0
Afficher les détails des licences
Licence et utilisation
Gratuit pour un usage personnel Attribution requise
Partager