Cours Génie Logiciel - Cours 2 - Cycles de vie

Cours 2 :,[object Object],Cycles de vie de logiciels,[object Object],Cours IGLcours 2Cycles de vie de logiciels,[object Object],1,[object Object],Mostefai Mohammed Amine – m_mostefai@esi.dz,[object Object],Batata Sofiane – s_batata@esi.dz,[object Object]

Découvrir les principales activités de développement de logiciels,[object Object],Connaître les cycles de vie (SDLC) et leur motivation,[object Object],Connaître les SDLC classiques et les méthodes agiles,[object Object],Pourvoir choisir un SDLC sur la base des données concernant un projet de développement,[object Object],Prise de contact avec la méthodologie UP,[object Object],Découvrir les outils de support (CASE),[object Object],Objectifs du cours,[object Object],2,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Objectifs du cours,[object Object]

Cours 2,[object Object],Cycles de vie de logiciels,[object Object],3,[object Object],Introduction au génie logiciel,[object Object]

Cycles de vie de logiciels,[object Object],4,[object Object],Cours igl,[object Object],Section 1 : Activités de développement,[object Object]

Tout logiciel passe par plusieurs étapes pour être développé,[object Object],Ces étapes peuvent être résumées dans les étapes ci-dessous :,[object Object],Section 1 - introduction,[object Object],5,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Etapes de développement,[object Object]

Définir les besoins :,[object Object],Que doit faire le logiciel,[object Object],De quelle façon,[object Object],Et sous quelles conditions,[object Object],Section 1 - introduction,[object Object],6,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Définition,[object Object]

Transformation des données collectées pendant l’étape de définition en plusieurs produits :,[object Object],Logiciel fonctionnel,[object Object],Code source,[object Object],Produits connexes,[object Object],Section 1 - introduction,[object Object],7,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Développement,[object Object]

Section 1 - introduction,[object Object],8,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Support,[object Object]

Correction : réparation des fonctions qui ne marchent pas ou qui ne marchent pas comme souhaité.,[object Object],Adaptation : adaptation de fonctions aux évolutions technologiques actuelles. ,[object Object],Amélioration : en terme de performance, ergonomie, …,[object Object],Prévention : Rendre le logiciel plus facile à la maintenance,[object Object],Section 1 - introduction,[object Object],9,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Support,[object Object]

Chaque projet de développement est composé de plusieurs activités,[object Object],Chaque activité est conduite et réalisée par plusieurs acteurs,[object Object],Une activité a des entrées et des sorties. Les livrables font partie des sorties des activités,,[object Object],Les livrables sont des produits ou des documents produits par une activités et utilisé par les activités qui en dépendent,[object Object],Par exemple : document, planning, code source sont tous des livrables,[object Object],Section 1 - introduction,[object Object],10,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Activités,[object Object]

Tous les projets de développement ont des activités communes,[object Object],Section 1 - introduction,[object Object],11,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Principales activités,[object Object]

Conditions qui doivent être respectées par un nouveau produit ou un produit altéré,[object Object],Aussi appelé spécifications,[object Object],Dans les grands projets (par exemple projets nationaux), c’est composé d’un cahier de charges,[object Object],Cette phase est difficile car le client et les développeurs ne parlent pas le même langage,[object Object],Le livrable de cette phase est un document de spécification,[object Object],Section 1 - introduction,[object Object],12,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Analyse de besoins,[object Object]

La conception utilise les spécifications pour décider les solutions relatives au différents problèmes de développement,[object Object],La conception décide aussi d’un planning de la solution,[object Object],La conception décide de l’architecture de la solution,[object Object],Si le produit est centré sur l’utilisateur, la conception propose une ébauche de l’interface utilisateur,[object Object],Section 1 - introduction,[object Object],13,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Conception,[object Object]

Le codage est une activité très importante du GL,[object Object],Le codage transforme les solutions proposées lors de la conception en un code opérationnel,[object Object],La conception et le codage peuvent toutes les deux produire du code source, mais c’est l’étape de codage qui rend ce code opérationnel.,[object Object],Les techniques de codage dépendent intrinsèquement du langage de programmation utilisé et du paradigme. ,[object Object],Section 1 - introduction,[object Object],14,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Codage,[object Object]

Les tests déterminent la qualité du logiciel,[object Object],Les tests déterminent si le logiciel fait ce qu’on attend de lui par rapport aux spécifications,[object Object],Plusieurs types de test dont deux principaux : tests unitaires et tests d’acceptation,[object Object],Les tests unitaires sont orientés code. Ils se rédigent durant l’activité de codage et se revérifient pendant la phase de test,[object Object],Les tests d’acceptation vérifient les attentes d’un produit logiciel,[object Object],Section 1 - introduction,[object Object],15,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Tests,[object Object]

La maintenance consiste à modifier le produit (le logiciel) après sa livraison au client,[object Object],Son but est correctif ou évolutif,[object Object],La maintenance a deux facettes : organisationnelle et technique,[object Object],L’aspect organisationnel concerne l’organisation des équipes pour une réactivité face aux changements,[object Object],L’aspect technique concerne une maintenance sans impact négatif sur le produit,[object Object],Le degré de maintenance dépend de la qualité de la conception,[object Object],Section 1 - introduction,[object Object],16,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Maintenance,[object Object]

Cycles de vie de logiciels,[object Object],17,[object Object],COURS IGL,[object Object],Débat (10 Mns),[object Object]

Cycles de vie de logiciels,[object Object],18,[object Object],Cours igl,[object Object],Section 2 : Cycle de vie de logiciels,[object Object]

Un procédé logiciel (software process) est un ensemble d’activités conduisant à la production d’un logiciel,[object Object],Ils sont aussi appelés cycle de vie d’un logiciel (SDLC),[object Object],Un procédé définit les étapes qui le composent ainsi que leur enchaînement,[object Object],Les Cycles de vie de logiciels sont complexes et dépendent fortement des acteurs qui dirigent les activités,[object Object],Les activités des procédés ne peuvent être automatisées mais il y a des outils de support, appelés outils CASE (Computer-Aided Software Engineering),[object Object],Section 2 – Cycles de vie de logiciels,[object Object],19,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Procédé Logiciel,[object Object]

Un modèle de procédé est une abstraction d’un procédé,[object Object],Un modèle décrit le procédé selon une certaine perspective,[object Object],Un procédé logiciel est une application d’un modèle pour un projet spécifique, qui peut inclure une certaine adaptation,[object Object],Section 2 – Cycles de vie de logiciels,[object Object],20,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèles de procédés,[object Object]

Pour maîtriser les gros projets,[object Object],Pour découper le projet et affecter correctement les tâches,[object Object],Pour anticiper et gérer les risques,[object Object],Section 2 – Cycles de vie de logiciels,[object Object],21,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèles de procédés – Pourquoi ?,[object Object]

Il existe deux types de modèles de procédés :,[object Object],Section 2 – Cycles de vie de logiciels,[object Object],22,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèles de procédés,[object Object]

Section 2 – Cycles de vie de logiciels,[object Object],23,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèles de procédés,[object Object]

Aucun modèle n’est meilleur que l’autre,[object Object],Le choix se fait selon certains critères tels que la nature du projet, sa taille, la nature du client et les compétences de l’équipe,[object Object],Section 2 – Cycles de vie de logiciels,[object Object],24,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Choix d’un modèle,[object Object]

Cycles de Vie des Logiciels,[object Object],25,[object Object],Cours igl,[object Object],Section 2 : Débat (5 mn),[object Object],[object Object]

Comment mesure-t-on un gros projet ?

Pourquoi un modèle de procédé est-il essentiel pour conduire un projet de développement ?,[object Object]

L’un des premiers modèles proposés, inspiré du modèle de Royce (1970),[object Object],Aussi appelé modèle linéaire,[object Object],Le résultat de chaque phase est un ensemble de livrables,,[object Object],Une phase ne peut démarrer que si la précédente est finie,[object Object],Le modèle académique par excellence,[object Object],Section 3 – modèles classiques,[object Object],27,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en cascade,[object Object]

Section 3 – modèles classiques,[object Object],28,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en cascade,[object Object]

Avantages :,[object Object],Facile à utiliser et à comprendre,[object Object],Un procédé structuré pour une équipe inexpérimentée,[object Object],Idéal pour la gestion et le suivi de projets,[object Object],Fonctionne très bien quand la qualité est plus importante que les coûts et les délais,[object Object],Section 3 – modèles classiques,[object Object],29,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en cascade,[object Object]

Inconvénients :,[object Object],Les besoins des clients sont très rarement stables et clairement définis,[object Object],Sensibilité aux nouveaux besoins : refaire tout le procédé,[object Object],Une phase ne peut démarrer que si l’étape précédente est finie,[object Object],Le produit n’est visible qu’à la fin,[object Object],Les risques se décalent vers la fin,[object Object],Très faible implication du client,[object Object],Section 3 – modèles classiques,[object Object],30,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en cascade,[object Object]

Quand l’utiliser ?,[object Object],Quand les besoins sont connus et stables,[object Object],Quand la technologie à utiliser est maîtrisée,[object Object],Lors de la création d’une nouvelle version d’un produit existant,[object Object],Lors du portage d’un produit sur une autre plateforme,[object Object],Section 3 – modèles classiques,[object Object],31,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en cascade,[object Object]

Variante du modèle en cascade qui fait l’accent sur la vérification et la validation,[object Object],Le test du produit se fait en parallèle par rapport aux autres activités,[object Object],Section 3 – modèles classiques,[object Object],32,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en V,[object Object]

Section 3 – modèles classiques,[object Object],33,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en V,[object Object]

Avantages :,[object Object],Met l’accent sur lest tests et la validation et par conséquent, ça accroît la qualité du logiciel,[object Object],Chaque livrable doit être testable,[object Object],Facile à planifier dans une gestion de projets,[object Object],Facile à utiliser,[object Object],Section 3 – modèles classiques,[object Object],34,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en V,[object Object]

Inconvénients :,[object Object],Ne gère pas les activités parallèles,[object Object],Ne gère pas explicitement les changements des spécifications,[object Object],Ne contient pas d’activités d’analyse de risque,[object Object],Section 3 – modèles classiques,[object Object],35,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en V,[object Object]

Quand l’utiliser:,[object Object],Quand le produit à développer à de très hautes exigences de qualité,[object Object],Quand les besoins sont connus à l’avance,[object Object],Les technologies à utiliser sont connues à l’avance,[object Object],Section 3 – modèles classiques,[object Object],36,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en V,[object Object]

Le projet se fait sur plusieurs itérations,[object Object],Les développeurs construisent un prototype selon les attentes du client,[object Object],Le prototype est évalué par le client,[object Object],Le client donne son feedback,[object Object],Les développeurs adaptent le prototype selon les besoins du client,[object Object],Quand le prototype satisfait le client, le code est normalisé selon les standards et les bonnes pratiques,[object Object],Section 3 – modèles classiques,[object Object],37,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Prototypage,[object Object]

Section 3 – modèles classiques,[object Object],38,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Prototypage,[object Object]

Avantages,[object Object],Implication active du client,[object Object],Le développeur apprend directement du client,[object Object],S’adapte rapidement aux changements des besoins,[object Object],Progrès constant et visible,[object Object],Une grande interaction avec le produit,[object Object],Section 3 – modèles classiques,[object Object],39,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Prototypage,[object Object]

Inconvénients,[object Object],Le prototypage implique un code faiblement structuré,[object Object],Degré très faible de maintenabilité,[object Object],Le processus peut ne jamais s’arrêter,[object Object],Très difficile d’établir un planning,[object Object],Section 3 – modèles classiques,[object Object],40,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Inconvénients,[object Object]

Quand l’utiliser ?,[object Object],Quand les besoins sont instables et/ou nécessitent des clarifications,[object Object],Peut être utilisé avec le modèle en cascade pour la clarification des besoins,[object Object],Quand des livraisons rapides sont exigées,[object Object],Section 3 – modèles classiques,[object Object],41,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Inconvénients,[object Object]

Chaque incrément est une construction partielle du logiciel,[object Object],Trie les spécifications par priorités et les regroupent dans des groupes de spécifications,[object Object],Chaque incrément implémente un ou plusieurs groupes jusqu’à ce que la totalité du produit soit finie,[object Object],Section 3 – modèles classiques,[object Object],42,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle Incrémental,[object Object]

Section 3 – modèles classiques,[object Object],43,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle Incrémental,[object Object],Incrément 1,[object Object],Incrément 2,[object Object],Incrément N,[object Object],Spécifications,[object Object],Conception,[object Object],Implémentation,[object Object],Tests,[object Object],Spécifications,[object Object],Conception,[object Object],Implémentation,[object Object],Tests,[object Object],Spécifications,[object Object],Conception,[object Object],Implémentation,[object Object],Tests,[object Object]

Avantages,[object Object],Développement de fonctionnalités à risque en premier,[object Object],Chaque incrément donne un produit fonctionnel,[object Object],Le client intervient à la fin de chaque incrément,[object Object],Utiliser l’approche « diviser pour régner »,[object Object],Le client entre en relation avec le produit très tôt,[object Object],Section 3 – modèles classiques,[object Object],44,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle Incrémental,[object Object]

Inconvénients,[object Object],Exige une bonne planification et une bonne conception,[object Object],Exige une vision sur le produit fini pour pouvoir le diviser en incréments,[object Object],Le coût total du système peut être cher,[object Object],Section 3 – modèles classiques,[object Object],45,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle Incrémental,[object Object]

Quand l’utiliser ?,[object Object],Quand la plupart des spécifications sont connues à l’avances et vont être sujettes à de faibles évolutions,[object Object],Quand on veut rapidement un produit fonctionnel,[object Object],Pour des projets de longues durées,[object Object],Pour des projets impliquant de nouvelles technologies,[object Object],Section 3 – modèles classiques,[object Object],46,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle Incrémental,[object Object]

Modèle itératif,[object Object],Des incréments sous forme de cycle,[object Object],À la fin de chaque cycle on détermine les objectifs du cycle suivant,[object Object],Chaque cycle est composé des même activités que du modèle en cascade,[object Object],Inclut l’analyse de risque et le prototypage,[object Object],Section 3 – modèles classiques,[object Object],47,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en spirale,[object Object]

Section 3 – modèles classiques,[object Object],48,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en spirale,[object Object]

Détermination des objectifs,[object Object],En terme de fonctionnalité, de performance, de coût,...etc.,[object Object],Déterminer les alternatives : développer, réutiliser, acheter, sous-traiter…etc.,[object Object],Contraintes : coûts, plannings, … etc.,[object Object],Section 3 – modèles classiques,[object Object],49,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en spirale,[object Object]

Identification et évaluation de risques,[object Object],Etudier les alternatives de développement,[object Object],Identification des risques : technologie non maîtrisées, équipe peu expérimentée, planning trop serré, …etc.,[object Object],Evaluation des risques : voir si les risques peuvent impacter le projet et à quel degré,[object Object],Section 3 – modèles classiques,[object Object],50,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en spirale,[object Object]

Développement et test,[object Object],Contient pratiquement la plupart des activités : conception, codage, test, … etc.,[object Object],Planification de la prochaine itération,[object Object],Un planning de l’itération,[object Object],Un plan de tests,[object Object],Section 3 – modèles classiques,[object Object],51,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en spirale,[object Object]

Avantages,[object Object],Identification rapide des risques,[object Object],Impacts minimaux des risques sur le projet,[object Object],Fonctions critiques développées en premier,[object Object],Feedback rapide du client,[object Object],Une évaluation continue du procédé,[object Object],Section 3 – modèles classiques,[object Object],52,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en spirale,[object Object]

Inconvénients,[object Object],L’évaluation des risques peut prendre beaucoup de temps,[object Object],Le modèle est très complexe,[object Object],La spirale peut s’éterniser,[object Object],Les développeurs doivent être réaffectés pendant les phases de non-développement,[object Object],Les objectifs ne sont pas souvent faciles à formuler,[object Object],Section 3 – modèles classiques,[object Object],53,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en spirale,[object Object]

Quand est-ce que l’utiliser ?,[object Object],Quand le prototypage est exigé,[object Object],Quand le risque du projet est considérable,[object Object],Quand les spécifications ne sont pas stables,[object Object],Pour les nouveaux produits,[object Object],Quand le projet implique de la recherche et de l’investigation,[object Object],Section 3 – modèles classiques,[object Object],54,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Modèle en spirale,[object Object]

Cycles de vie de logiciels,[object Object],55,[object Object],Cours igl,[object Object],Section 3 : Débat (15 Mn),[object Object],[object Object]

Quels sont les critères qui définiront quel modèle choisir ?

Quelle est la chose la plus difficile pour un modèle incrémental ou itératif ?,[object Object]

Au milieu des années 90, un groupe d’expert en Cycles de vie de logiciels voulaient proposer de nouveaux modèles,[object Object],Les nouveaux modèles sont plus « légers » : moins de documentation et moins de contrôle sur le procédé,[object Object],Ces modèles s’adresse à des projets de petite ou moyenne taille avec une équipe réduite,[object Object],Ces modèles permettent de s’ajuster rapidement aux changements des spécifications tout en garantissant des livraisons fréquentes,[object Object],Ces modèles sont qualifiés de « modèles agiles »,[object Object],Section 4 – méthodes agiles,[object Object],57,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Apparition,[object Object]

Section 4 – méthodes agiles,[object Object],58,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Principes agiles,[object Object]

INDIVIDUS ET INTERACTIONS AU LIEU DE PROCESSUS ET OUTILS,[object Object],Les collaborateurs sont la clé du succès,[object Object],Les « seniors » échoueront s’ils ne collaborent pas en tant qu’équipe,[object Object],Un bon collaborateur n’est pas un forcément un bon programmeur. C’est quelqu’un qui travaille bien en équipe,[object Object],Une surabondance d’outils est aussi mauvaise que le manque d’outils,[object Object],Démarrer petit et investir peu au démarrage,[object Object],Construire l’équipe c’est plus important que construire l’environnement,[object Object],Section 4 – méthodes agiles,[object Object],59,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Principes,[object Object]

LOGICIEL FONCTIONNEL AU LIEU DE DOCUMENTATION MASSIVE,[object Object],Un code sans documentation est un désastre,[object Object],Trop de documents est pire que pas de documents,[object Object],Difficulté à produire et à synchroniser avec le code,[object Object],Souvent les documents sont des « mensonges » formels,[object Object],Le code ne ment jamais sur lui-même,[object Object],Produire toujours des documents aussi courts que possible,[object Object],Section 4 – méthodes agiles,[object Object],60,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Principes,[object Object]

COLLABORATION DU CLIENT AU LIEU DE LA NÉGOCIATION DE CONTRATS,[object Object],Très difficile de décrire la totalité du logiciel depuis le début,[object Object],Les projets réussis impliquent les clients d’une manière fréquente et régulière,[object Object],Le client doit avoir un contact direct avec l’équipe de développement,[object Object],Section 4 – méthodes agiles,[object Object],61,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Principes,[object Object]

RÉAGIR AUX CHANGEMENTS AU LIEU DE SUIVRE UN PLAN,[object Object],Un logiciel ne peut pas être planifié très loin dans le futur,[object Object],Tout change : technologie, environnement et surtout les besoins,[object Object],Les chefs de projets classiques fonctionnent sur la base de GANTT, PERT et le système de tâches,[object Object],Avec le temps, les diagrammes se dégradent car des tâches s’ajoutent et d’autres deviennent non nécessaires,[object Object],Une meilleure stratégie est de planifier très court (02 semaines à 01 mois),[object Object],Plannings détaillés pour la semaine à venir, rigoureux pour les trois mois et très vagues au-delà,[object Object],Section 4 – méthodes agiles,[object Object],62,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Principes,[object Object]

LES DOUZE PRINCIPES AGILES,[object Object],Toujours satisfaire le client à travers des livraisons rapides et continues,[object Object],Bien accueillir tous les changements même les tardifs,[object Object],Livrer fréquemment un système fonctionnel,[object Object],Les clients et les développeurs doivent collaborer,[object Object],Conduire le projet autour d’équipes motivées,[object Object],La meilleure méthode de faire circuler l’information c’est le contact direct entre collaborateurs,[object Object],La première mesure d’avancement c’est un logiciel fonctionnel,[object Object],Section 4 – méthodes agiles,[object Object],63,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Principes,[object Object]

LES DOUZE PRINCIPES AGILES,[object Object],Le développement doit être durable et à un rythme constant,[object Object],La bonne conception et l’excellence technique augmentent l’agilité,[object Object],Simplifier au maximum,[object Object],Les meilleurs architectures, besoins et conceptions proviennent d’équipes qui s’organisent d’elles-mêmes,[object Object],L’équipe s’améliore d’une manière autonome et régulière,[object Object],Section 4 – méthodes agiles,[object Object],64,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Principes,[object Object]

Section 4 – méthodes agiles,[object Object],65,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Principales méthodologies agiles,[object Object]

eXtreme Programming,[object Object],Créée en 1995 Kent Beck and Ward Cunningham,[object Object],XP est un moyen léger, efficace, à bas risques, flexible, scientifique et amusant de développer des logiciels,[object Object],Destinée à des équipes de moyenne taille avec des spécifications incomplets et / ou vagues,[object Object],Le codage est le noyau de XP,[object Object],Section 4 – méthodes agiles,[object Object],66,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Méthodologie XP,[object Object]

Section 4 – méthodes agiles,[object Object],67,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Méthodologie XP - Fondamentaux,[object Object]

Section 4 – méthodes agiles,[object Object],68,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Méthodologie XP – Principales activités,[object Object]

1- LE JEU DE PLANNING : ,[object Object],Le client et les développeurs décident quoi mettre dans la prochaine livraison en triant les spécifications par priorité,[object Object],L’estimation est la responsabilité du développeur, pas du chef de projet ni du client,[object Object],2 – DE PETITES ET FRÉQUENTES LIVRAISONS :,[object Object],D’abord livrer un système minimaliste puis le faire évoluer à travers des versions à des délais très courts,[object Object],Section 4 – méthodes agiles,[object Object],69,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Méthodologie XP – Les 12 pratiques,[object Object]

3- LES MÉTAPHORES,[object Object],Exprimer de manière naturelle et très simples des fonctions du système,[object Object],Le client et les développeurs doivent s’accorder sur les métaphores,[object Object],4 – CONCEPTION SIMPLE,[object Object],Le système doit être conçu de la manière la plus simple possible,[object Object],5 – TESTS,[object Object],Les développeurs rédigent les tests unitaires d’une manière continue, Le client rédige les tests d’acceptation des fonctionnalités,,[object Object],Section 4 – méthodes agiles,[object Object],70,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Méthodologie XP – Les 12 pratiques,[object Object]

6 – REFACTORING,[object Object],Les développeurs améliorent continuellement le code tout en veillant à le garder fonctionnel,[object Object],7 – PROGRAMMATION PAR PAIRES,[object Object],La totalité du code est écrite par deux programmeurs sur une seule machine. L’un est appelé conducteur (driver) et l’autre navigateur. Les rôles s’inversent régulièrement.,[object Object],8 - PROPRIÉTÉ COLLECTIVE,[object Object],N’importe qui peut changer le code n’importe où dans le système à n’importe quel moment,[object Object],9 - 40 HEURES LA SEMAINE,[object Object],Le travail ne doit pas dépasser 40 heures par semaine,[object Object],Section 4 – méthodes agiles,[object Object],71,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Méthodologie XP – Les 12 pratiques,[object Object]

10 – intégration continue,[object Object],Construire le système à chaque fois qu’une tâche est terminée.,[object Object],11 – Le client est sur site,[object Object],Le client est tout le temps présent avec l’équipe pour participer et répondre aux questions,[object Object],12 – Les standards de codage,[object Object],À cause de la propriété collective, des standards (une charte de codage) doivent être établis et adhérés par l’équipe de développement,[object Object],Section 4 – méthodes agiles,[object Object],72,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Méthodologie XP – Les 12 pratiques,[object Object]

Implication active du client,[object Object],Forte réactivité des développeurs,[object Object],Responsabilisation et solidarité de l’équipe,[object Object],Appel aux meilleurs pratiques de développement,[object Object],Souplesse extrême,[object Object],Section 4 – méthodes agiles,[object Object],73,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Méthodologie XP – Avantages,[object Object]

Demande une certaine maturité des développeurs,[object Object],La programmation par paires n’est toujours pas applicable,[object Object],Difficulté de planifier et de budgétiser un projet,[object Object],Stress dû aux devoir de l’intégration continue et des livraisons fréquentes,[object Object],La faible documentation peut nuire en cas de départ des développeurs,[object Object],Section 4 – méthodes agiles,[object Object],74,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Méthodologie XP – Inconvénients,[object Object]

Inspiré par une approche développée en 1986 par H. Takeuchii et II.. Nonaka, le terme « Scrum » utilisé dans « Wiicked Problems, Rightteous Solutions » par DeGrace et Stahl en 1991,[object Object],Utilisé comme méthodologie dans le livre : « Agile Software Developmentt with SCRUM” par K. Schwaber et M.. Beedlle en 2001,[object Object],Section 4 – méthodes agiles,[object Object],75,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Méthodologie Scrum,[object Object]

Section 4 – méthodes agiles,[object Object],76,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Méthodologie Scrum - Principes,[object Object]

Méthode très simple et très efficace,[object Object],Adoptée par les géants du marché : Microsoft, Google, Nokia..,[object Object],Orientée projet contrairement à XP qui est orientée développement,[object Object],Peut inclure d’autres activité venant d’autres méthodologies (surtout XP),[object Object],Section 4 – méthodes agiles,[object Object],79,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Méthodologie Scrum - Avantages,[object Object]

N’est pas 100% spécifique au GL,[object Object],Difficulté de budgétiser un projet,[object Object],Section 4 – méthodes agiles,[object Object],80,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Méthodologie Scrum - Inconvénients,[object Object]

Cycles de vie de logiciels,[object Object],81,[object Object],Cours igl,[object Object],Section 4 : Débat (10 mns),[object Object],[object Object]

Quels sont les points forts des méthodes agiles ?

Quels en sont les points faibles ?

Quelle est la différence entre Scrum et XP ?

Est-ce que Scrum et XP peuvent-elles être combinées ?,[object Object]

UP est un modèle de procédé très populaire,[object Object],UP est incrémental et itératif,[object Object],UP a plusieurs implémentation et / ou variation dont la plus célèbre est RUP (Rational Unified Process),[object Object],Section 5 – méthodologie up,[object Object],83,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP,[object Object]

Section 5 – méthodologie up,[object Object],84,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Implémentations,[object Object]

Section 5 – méthodologie up,[object Object],85,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Principes,[object Object]

PROCESSUS ITÉRATIF ET INCRÉMENTAL,[object Object],UP est composé de quatre phase : l’analyse de besoins (inception), l’élaboration, la construction et la transition,[object Object],Chaque phase peut être décomposée en plusieurs itérations,[object Object],Chaque itération produit un incrément du produit,[object Object],Section 5 – méthodologie up,[object Object],86,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP - Principes,[object Object]

PROCESSUS BASÉ SUR LES CAS D’UTILISATION,[object Object],Les cas d’utilisation formalisent les spécifications fonctionnelle du produit,[object Object],Chaque itérations prend un ensemble de cas d’utilisation et les traite selon plusieurs workflows : modélisation métier, analyse de besoins, analyse et conception, implémentation, tests et déploiement,[object Object],Section 5 – méthodologie up,[object Object],87,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP - Principes,[object Object]

PROCESSUS CENTRÉ SUR L’ARCHITECTURE,[object Object],UP supporte plusieurs architectures logicielles,[object Object],La phase d’élaboration fournit l’architecture de l’exécutable,[object Object],Cette architecture est une implémentation partielle qui sert de fondation aux développements futurs,[object Object],Section 5 – méthodologie up,[object Object],88,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP - Principes,[object Object]

PROCESSUS QUI MET L’ACCENT SUR LES RISQUES,[object Object],Identification rapide des risques,[object Object],Traitement des risques dans les premières phases du projet,[object Object],Section 5 – méthodologie up,[object Object],89,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP - Principes,[object Object]

UP est composé de quatre phases principales : analyse de besoins (inception), élaboration, construction et transition,[object Object],Section 5 – méthodologie up,[object Object],90,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Cycle de vie,[object Object]

UP est un processus bidimensionnel,[object Object],La phase horizontale représente le temps et les étapes,[object Object],La phase verticale représente les activités,[object Object],Section 5 – méthodologie up,[object Object],91,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Cycle de vie,[object Object]

Section 5 – méthodologie up,[object Object],92,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Cycle de vie,[object Object]

PHASE D’ANALYSE DE BESOINS (INCEPTION),[object Object],La plus petite phase et la plus courte,[object Object],Etablit une vision globale du projet,[object Object],Essaye d’identifier les principaux cas d’utilisations,[object Object],Propose une ou plusieurs architectures du système,[object Object],Identifie les risques,[object Object],Etablit un planning préliminaire,[object Object],Peut annuler le projet si l’étape prend trop de temps,[object Object],Section 5 – méthodologie up,[object Object],93,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Cycle de vie,[object Object]

PHASE D’ÉLABORATION,[object Object],Capturer la majorité des cas d’utilisation,[object Object],Valider l’architecture du système,[object Object],Eliminer les facteurs de risque,[object Object],Peut décider de ne pas aller au-delà,[object Object],Livrable : prototype exécutable d’architecture,[object Object],Livrable : un planning détaillé et précis sur la phase de construction,[object Object],Section 5 – méthodologie up,[object Object],94,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Cycle de vie,[object Object]

PHASE DE CONSTRUCTION,[object Object],La phase la plus longue du projet,[object Object],Le reste du système est développé durant cette phase,[object Object],Chaque itération produit un incrément vers le système final,[object Object],Section 5 – méthodologie up,[object Object],95,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Cycle de vie,[object Object]

PHASE DE TRANSITION,[object Object],Le système est déployé chez les utilisateurs,[object Object],Les feedbacks récoltés serviront à améliorer le système,[object Object],Section 5 – méthodologie up,[object Object],96,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Cycle de vie,[object Object]

Expression de besoins,[object Object],Recenser les besoins fonctionnels et non fonctionnels du système,[object Object],Le diagramme UML de cas d’utilisation est utilisé pour cette phase,[object Object],Section 5 – méthodologie up,[object Object],97,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Activités,[object Object]

Analyse,[object Object],Détaille les besoins en spécifications détaillées,[object Object],Une ébauche de la conception,[object Object],Section 5 – méthodologie up,[object Object],98,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Activités,[object Object]

Conception,[object Object],Décide comment sera construit le système durant l’implémentation,[object Object],Définition des sous-systèmes et composants,[object Object],Création d’abstractions de la solution,[object Object],Section 5 – méthodologie up,[object Object],99,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Activités,[object Object]

Implémentation,[object Object],Traduire les résultats de la conception en un système opérationnel,[object Object],Livrables : code source, exécutables, …etc.,[object Object],Section 5 – méthodologie up,[object Object],100,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Activités,[object Object]

Tests,[object Object],Vérification et validation des résultats de l’implémentation,[object Object],Section 5 – méthodologie up,[object Object],101,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Activités,[object Object]

Méthodologie complète,[object Object],Identification rapide des risques,[object Object],Largement adoptée en entreprise,[object Object],Intégration avec UML,[object Object],Séparation concise des phases et des livrables,[object Object],Des formations / livres / tutoriaux disponibles,[object Object],Section 5 – méthodologie up,[object Object],102,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],UP – Avantages,[object Object]

Cycles de vie de logiciels,[object Object],103,[object Object],Cours igl,[object Object],Débat (05 Mns),[object Object],[object Object]

C’est une méthode bidimensionnelle, pourquoi ?

C’est une méthode itérative et incrémentale, pourquoi ?

Pourquoi est-elle largement adoptée à votre avis ?,[object Object]

CASE est un nom donné aux logiciels utilisés dans les différentes activités de GL (besoins, conception,…),[object Object],Exemples : compilateurs, éditeurs, débogueurs, …etc.,[object Object],Le but des outils CASE est d’automatiser les tâches et / ou gérer le projet de développement,[object Object],Outils case,[object Object],105,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Introduction,[object Object]

Le développement est essentiellement basé sur l’intelligence humaine, là, les outils CASE ne peuvent pas trop intervenir,[object Object],Le gros d’un projet de développement c’est la communication entre les membre de l’équipe. Là aussi, les CASE n’ont pas une grande intervention.,[object Object],Outils case,[object Object],106,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Limite des CASE,[object Object]

Les outils CASE peuvent être classés :,[object Object],D’un point de vue fonctionnel : selon la fonction de l’outil.,[object Object],D’un point de vue activité : selon les activités dans lesquelles intervient l’outil,[object Object],Outils case,[object Object],107,[object Object],Cours 2 – Cycle de vie de logiciels,[object Object],Classification des CASE,[object Object]

Cours Génie Logiciel - Cours 2 - Cycles de vie

Cours Génie Logiciel - Cours 2 - Cycles de vie

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados(20)

Similar a Cours Génie Logiciel - Cours 2 - Cycles de vie

Similar a Cours Génie Logiciel - Cours 2 - Cycles de vie(20)

Mais de Mohammed Amine Mostefai

Mais de Mohammed Amine Mostefai(20)

Cours Génie Logiciel - Cours 2 - Cycles de vie