Cours 2 :<br />Cycles de vie de logiciels<br />Cours IGLcours 2Cycles de vie de logiciels<br />1<br />Mostefai Mohammed Am...
Découvrir les principales activités de développement de logiciels<br />Connaître les cycles de vie (SDLC) et leur motivati...
Cours 2<br />Cycles de vie de logiciels<br />3<br />Introduction au génie logiciel<br />
Cycles de vie de logiciels<br />4<br />Cours igl<br />Section 1 : Activités de développement<br />
Tout logiciel passe par plusieurs étapes pour être développé<br />Ces étapes peuvent être résumées dans les étapes ci-dess...
Définir les besoins :<br />Que doit faire le logiciel<br />De quelle façon<br />Et sous quelles conditions<br />Section 1 ...
Transformation des données collectées pendant l’étape de définition en plusieurs produits :<br />Logiciel fonctionnel<br /...
Section 1 - introduction<br />8<br />Cours 2 – Cycle de vie de logiciels<br />Support<br />
Correction : réparation des fonctions qui ne marchent pas ou qui ne marchent pas comme souhaité.<br />Adaptation : adaptat...
Chaque projet de développement est composé de plusieurs activités<br />Chaque activité est conduite et réalisée par plusie...
Tous les projets de développement ont des activités communes<br />Section 1 - introduction<br />11<br />Cours 2 – Cycle de...
Conditions qui doivent être respectées par un nouveau produit ou un produit altéré<br />Aussi appelé spécifications<br />D...
La conception utilise les spécifications pour décider les solutions relatives au différents problèmes de développement<br ...
Le codage est une activité très importante du GL<br />Le codage transforme les solutions proposées lors de la conception e...
Les tests déterminent la qualité du logiciel<br />Les tests déterminent si le logiciel fait ce qu’on attend de lui par rap...
La maintenance consiste à modifier le produit (le logiciel) après sa livraison au client<br />Son but est correctif ou évo...
Cycles de vie de logiciels<br />17<br />COURS IGL<br />Débat (10 Mns)<br />
Cycles de vie de logiciels<br />18<br />Cours igl<br />Section 2 : Cycle de vie de logiciels<br />
Un procédé logiciel (software process) est un ensemble d’activités conduisant à la production d’un logiciel<br />Ils sont ...
Un modèle de procédé est une abstraction d’un procédé<br />Un modèle décrit le procédé selon une certaine perspective<br /...
Pour maîtriser les gros projets<br />Pour découper le projet et affecter correctement les tâches<br />Pour anticiper et gé...
Il existe deux types de modèles de procédés :<br />Section 2 – Cycles de vie de logiciels<br />22<br />Cours 2 – Cycle de ...
Section 2 – Cycles de vie de logiciels<br />23<br />Cours 2 – Cycle de vie de logiciels<br />Modèles de procédés<br />
Aucun modèle n’est meilleur que l’autre<br />Le choix se fait selon certains critères tels que la nature du projet, sa tai...
Cycles de Vie des Logiciels<br />25<br />Cours igl<br />Section 2 : Débat (5 mn)<br /><ul><li>Qu’est-ce qu’un gros projet ?
Comment mesure-t-on un gros projet ?
Pourquoi un modèle de procédé est-il essentiel pour conduire un projet de développement ?</li></li></ul><li>Cycles de vie ...
L’un des premiers modèles proposés, inspiré du modèle de Royce (1970)<br />Aussi appelé modèle linéaire<br />Le résultat d...
Section 3 – modèles classiques<br />28<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en cascade<br />
Avantages :<br />Facile à utiliser et à comprendre<br />Un procédé structuré pour une équipe inexpérimentée<br />Idéal pou...
Inconvénients  :<br />Les besoins des clients sont très rarement stables et clairement définis<br />Sensibilité aux nouvea...
Quand l’utiliser ?<br />Quand les besoins sont connus et stables<br />Quand la technologie à utiliser est maîtrisée<br />L...
Variante du modèle en cascade qui fait l’accent sur la vérification et la validation<br />Le test du produit se fait en pa...
Section 3 – modèles classiques<br />33<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en V<br />
Avantages :<br />Met l’accent sur lest tests et la validation et par conséquent, ça accroît la qualité du logiciel<br />Ch...
Inconvénients :<br />Ne gère pas les activités parallèles<br />Ne gère pas explicitement les changements des spécification...
Quand l’utiliser:<br />Quand le produit à développer à de très hautes exigences de qualité<br />Quand les besoins sont con...
Le projet se fait sur plusieurs itérations<br />Les développeurs construisent un prototype selon les attentes du client<br...
Section 3 – modèles classiques<br />38<br />Cours 2 – Cycle de vie de logiciels<br />Prototypage<br />
Avantages<br />Implication active du client<br />Le développeur apprend directement du client<br />S’adapte rapidement aux...
Inconvénients<br />Le prototypage implique un code faiblement structuré<br />Degré très faible de maintenabilité<br />Le p...
Quand l’utiliser ?<br />Quand les besoins sont instables et/ou nécessitent des clarifications<br />Peut être utilisé avec ...
Chaque incrément est une construction partielle du logiciel<br />Trie les spécifications par priorités et les regroupent d...
Section 3 – modèles classiques<br />43<br />Cours 2 – Cycle de vie de logiciels<br />Modèle Incrémental<br />Incrément 1<b...
Avantages<br />Développement de fonctionnalités à risque en premier<br />Chaque incrément donne un produit fonctionnel<br ...
Inconvénients<br />Exige une bonne planification et une bonne conception<br />Exige une vision sur le produit fini pour po...
Quand l’utiliser ?<br />Quand la plupart des spécifications sont connues à l’avances et vont être sujettes à de faibles év...
Modèle itératif<br />Des incréments sous forme de cycle<br />À la fin de chaque cycle on détermine les objectifs du cycle ...
Section 3 – modèles classiques<br />48<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en spirale<br />
Détermination des objectifs<br />En terme de fonctionnalité, de performance, de coût,...etc.<br />Déterminer les alternati...
Identification et évaluation de risques<br />Etudier les alternatives de développement<br />Identification des risques : t...
Développement et test<br />Contient pratiquement la plupart des activités : conception, codage, test, … etc.<br />Planific...
Avantages<br />Identification rapide des risques<br />Impacts minimaux des risques sur le projet<br />Fonctions critiques ...
Inconvénients<br />L’évaluation des risques peut prendre beaucoup de temps<br />Le modèle est très complexe<br />La spiral...
Quand est-ce que l’utiliser ?<br />Quand le prototypage est exigé<br />Quand le risque du projet est considérable<br />Qua...
Cycles de vie de logiciels<br />55<br />Cours igl<br />Section 3 : Débat (15 Mn)<br /><ul><li>Quel est le modèle le plus s...
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 ?</li></li></ul><li>Cycles de vie de logiciel...
Au milieu des années 90, un groupe d’expert en Cycles de vie de logiciels voulaient proposer de nouveaux modèles<br />Les ...
Section 4 – méthodes agiles<br />58<br />Cours 2 – Cycle de vie de logiciels<br />Principes agiles<br />
INDIVIDUS ET INTERACTIONS AU LIEU DE PROCESSUS ET OUTILS<br />Les collaborateurs sont la clé du succès<br />Les « seniors ...
LOGICIEL FONCTIONNEL AU LIEU DE DOCUMENTATION MASSIVE<br />Un code sans documentation est un désastre<br />Trop de documen...
COLLABORATION DU CLIENT AU LIEU DE LA NÉGOCIATION DE CONTRATS<br />Très difficile de décrire la totalité du logiciel depui...
RÉAGIR AUX CHANGEMENTS AU LIEU DE SUIVRE UN PLAN<br />Un logiciel ne peut pas être planifié très loin dans le futur<br />T...
LES DOUZE PRINCIPES AGILES<br />Toujours satisfaire le client à travers des livraisons rapides et continues<br />Bien accu...
LES DOUZE PRINCIPES AGILES<br />Le développement doit être durable et à un rythme constant<br />La bonne conception et l’e...
Section 4 – méthodes agiles<br />65<br />Cours 2 – Cycle de vie de logiciels<br />Principales méthodologies agiles<br />
eXtreme Programming<br />Créée en 1995 Kent Beck and Ward Cunningham<br />XP est un moyen léger, efficace, à bas risques, ...
Section 4 – méthodes agiles<br />67<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie XP - Fondamentaux<br />
Section 4 – méthodes agiles<br />68<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie XP – Principales activités<...
1- LE JEU DE PLANNING : <br />Le client et les développeurs décident quoi mettre dans la prochaine livraison en triant les...
3- LES MÉTAPHORES<br />Exprimer de manière naturelle et très simples des fonctions du système<br />Le client et les dévelo...
6 – REFACTORING<br />Les développeurs améliorent continuellement le code tout en veillant à le garder fonctionnel<br />7 –...
10 – intégration continue<br />Construire le système à chaque fois qu’une tâche est terminée.<br />11 – Le client est sur ...
Implication active du client<br />Forte réactivité des développeurs<br />Responsabilisation et solidarité de l’équipe<br /...
Demande une certaine maturité des développeurs<br />La programmation par paires n’est toujours pas applicable<br />Difficu...
Inspiré par une approche développée en 1986 par H. Takeuchii et II.. Nonaka, le terme « Scrum » utilisé dans « Wiicked Pro...
Section 4 – méthodes agiles<br />76<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie Scrum - Principes<br />
Section 4 – méthodes agiles<br />77<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie Scrum - Principes<br />
Section 4 – méthodes agiles<br />78<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie Scrum - Principes<br />
Méthode très simple et très efficace<br />Adoptée par les géants du marché : Microsoft, Google, Nokia..<br />Orientée proj...
N’est pas 100% spécifique au GL<br />Difficulté de budgétiser un projet<br />Section 4 – méthodes agiles<br />80<br />Cour...
Cycles de vie de logiciels<br />81<br />Cours igl<br />Section 4 : Débat (10 mns)<br /><ul><li>Quelles sont les différence...
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 ?</li></li></ul><li>Cycles de vie de logiciels<br />82<br />Cours igl<...
UP est un modèle de procédé très populaire<br />UP est incrémental et itératif<br />UP a plusieurs implémentation et / ou ...
Section 5 – méthodologie up<br />84<br />Cours 2 – Cycle de vie de logiciels<br />UP – Implémentations<br />
Section 5 – méthodologie up<br />85<br />Cours 2 – Cycle de vie de logiciels<br />UP – Principes<br />
PROCESSUS ITÉRATIF ET INCRÉMENTAL<br />UP est composé de quatre phase : l’analyse de besoins (inception), l’élaboration, l...
PROCESSUS BASÉ SUR LES CAS D’UTILISATION<br />Les cas d’utilisation formalisent les spécifications fonctionnelle du produi...
PROCESSUS CENTRÉ SUR L’ARCHITECTURE<br />UP supporte plusieurs architectures logicielles<br />La phase d’élaboration fourn...
PROCESSUS QUI MET L’ACCENT SUR LES RISQUES<br />Identification rapide des risques<br />Traitement des risques dans les pre...
UP est composé de quatre phases principales : analyse de besoins (inception), élaboration, construction et transition<br /...
UP est un processus bidimensionnel<br />La phase horizontale représente le temps et les étapes<br />La phase verticale rep...
Section 5 – méthodologie up<br />92<br />Cours 2 – Cycle de vie de logiciels<br />UP – Cycle de vie<br />
PHASE D’ANALYSE DE BESOINS (INCEPTION)<br />La plus petite phase et la plus courte<br />Etablit une vision globale du proj...
PHASE D’ÉLABORATION<br />Capturer la majorité des cas d’utilisation<br />Valider l’architecture du système<br />Eliminer l...
PHASE DE CONSTRUCTION<br />La phase la plus longue du projet<br />Le reste du système est développé durant cette phase<br ...
PHASE DE TRANSITION<br />Le système est déployé chez les utilisateurs<br />Les feedbacks récoltés serviront à améliorer le...
Expression de besoins<br />Recenser les besoins fonctionnels et non fonctionnels du système<br />Le diagramme UML de cas d...
Analyse<br />Détaille les besoins en spécifications détaillées<br />Une ébauche de la conception<br />Section 5 – méthodol...
Conception<br />Décide comment sera construit le système durant l’implémentation<br />Définition des sous-systèmes et comp...
Implémentation<br />Traduire les résultats de la conception en un système opérationnel<br />Livrables : code source, exécu...
Tests<br />Vérification et validation des résultats de l’implémentation<br />Section 5 – méthodologie up<br />101<br />Cou...
Méthodologie complète<br />Identification rapide des risques<br />Largement adoptée en entreprise<br />Intégration avec UM...
Cycles de vie de logiciels<br />103<br />Cours igl<br />Débat (05 Mns)<br /><ul><li>La méthode UP est-elle une méthode agi...
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 ?</li></li></ul><li>Cycles de vie de logiciels<br />104<br />Cours igl<br...
CASE est un nom donné aux logiciels utilisés dans les différentes activités de GL (besoins, conception,…)<br />Exemples : ...
Le développement est essentiellement basé sur l’intelligence humaine, là, les outils CASE ne peuvent pas trop intervenir<b...
Les outils CASE peuvent être classés :<br />D’un point de vue fonctionnel : selon la fonction de l’outil.<br />D’un point ...
Prochain SlideShare
Chargement dans…5
×

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

49 664 vues

Publié le

Une vue d'ensemble sur les cycles de vie et les procédés logiciels. Un bref tour de quelques méthodes agiles aussi.

14 commentaires
69 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
49 664
Sur SlideShare
0
Issues des intégrations
0
Intégrations
507
Actions
Partages
0
Téléchargements
0
Commentaires
14
J’aime
69
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

  1. 1. Cours 2 :<br />Cycles de vie de logiciels<br />Cours IGLcours 2Cycles de vie de logiciels<br />1<br />Mostefai Mohammed Amine – m_mostefai@esi.dz<br />Batata Sofiane – s_batata@esi.dz<br />
  2. 2. Découvrir les principales activités de développement de logiciels<br />Connaître les cycles de vie (SDLC) et leur motivation<br />Connaître les SDLC classiques et les méthodes agiles<br />Pourvoir choisir un SDLC sur la base des données concernant un projet de développement<br />Prise de contact avec la méthodologie UP<br />Découvrir les outils de support (CASE)<br />Objectifs du cours<br />2<br />Cours 2 – Cycle de vie de logiciels<br />Objectifs du cours<br />
  3. 3. Cours 2<br />Cycles de vie de logiciels<br />3<br />Introduction au génie logiciel<br />
  4. 4. Cycles de vie de logiciels<br />4<br />Cours igl<br />Section 1 : Activités de développement<br />
  5. 5. Tout logiciel passe par plusieurs étapes pour être développé<br />Ces étapes peuvent être résumées dans les étapes ci-dessous :<br />Section 1 - introduction<br />5<br />Cours 2 – Cycle de vie de logiciels<br />Etapes de développement<br />
  6. 6. Définir les besoins :<br />Que doit faire le logiciel<br />De quelle façon<br />Et sous quelles conditions<br />Section 1 - introduction<br />6<br />Cours 2 – Cycle de vie de logiciels<br />Définition<br />
  7. 7. Transformation des données collectées pendant l’étape de définition en plusieurs produits :<br />Logiciel fonctionnel<br />Code source<br />Produits connexes<br />Section 1 - introduction<br />7<br />Cours 2 – Cycle de vie de logiciels<br />Développement<br />
  8. 8. Section 1 - introduction<br />8<br />Cours 2 – Cycle de vie de logiciels<br />Support<br />
  9. 9. Correction : réparation des fonctions qui ne marchent pas ou qui ne marchent pas comme souhaité.<br />Adaptation : adaptation de fonctions aux évolutions technologiques actuelles. <br />Amélioration : en terme de performance, ergonomie, …<br />Prévention : Rendre le logiciel plus facile à la maintenance<br />Section 1 - introduction<br />9<br />Cours 2 – Cycle de vie de logiciels<br />Support<br />
  10. 10. Chaque projet de développement est composé de plusieurs activités<br />Chaque activité est conduite et réalisée par plusieurs acteurs<br />Une activité a des entrées et des sorties. Les livrables font partie des sorties des activités,<br />Les livrables sont des produits ou des documents produits par une activités et utilisé par les activités qui en dépendent<br />Par exemple : document, planning, code source sont tous des livrables<br />Section 1 - introduction<br />10<br />Cours 2 – Cycle de vie de logiciels<br />Activités<br />
  11. 11. Tous les projets de développement ont des activités communes<br />Section 1 - introduction<br />11<br />Cours 2 – Cycle de vie de logiciels<br />Principales activités<br />
  12. 12. Conditions qui doivent être respectées par un nouveau produit ou un produit altéré<br />Aussi appelé spécifications<br />Dans les grands projets (par exemple projets nationaux), c’est composé d’un cahier de charges<br />Cette phase est difficile car le client et les développeurs ne parlent pas le même langage<br />Le livrable de cette phase est un document de spécification<br />Section 1 - introduction<br />12<br />Cours 2 – Cycle de vie de logiciels<br />Analyse de besoins<br />
  13. 13. La conception utilise les spécifications pour décider les solutions relatives au différents problèmes de développement<br />La conception décide aussi d’un planning de la solution<br />La conception décide de l’architecture de la solution<br />Si le produit est centré sur l’utilisateur, la conception propose une ébauche de l’interface utilisateur<br />Section 1 - introduction<br />13<br />Cours 2 – Cycle de vie de logiciels<br />Conception<br />
  14. 14. Le codage est une activité très importante du GL<br />Le codage transforme les solutions proposées lors de la conception en un code opérationnel<br />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.<br />Les techniques de codage dépendent intrinsèquement du langage de programmation utilisé et du paradigme. <br />Section 1 - introduction<br />14<br />Cours 2 – Cycle de vie de logiciels<br />Codage<br />
  15. 15. Les tests déterminent la qualité du logiciel<br />Les tests déterminent si le logiciel fait ce qu’on attend de lui par rapport aux spécifications<br />Plusieurs types de test dont deux principaux : tests unitaires et tests d’acceptation<br />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<br />Les tests d’acceptation vérifient les attentes d’un produit logiciel<br />Section 1 - introduction<br />15<br />Cours 2 – Cycle de vie de logiciels<br />Tests<br />
  16. 16. La maintenance consiste à modifier le produit (le logiciel) après sa livraison au client<br />Son but est correctif ou évolutif<br />La maintenance a deux facettes : organisationnelle et technique<br />L’aspect organisationnel concerne l’organisation des équipes pour une réactivité face aux changements<br />L’aspect technique concerne une maintenance sans impact négatif sur le produit<br />Le degré de maintenance dépend de la qualité de la conception<br />Section 1 - introduction<br />16<br />Cours 2 – Cycle de vie de logiciels<br />Maintenance<br />
  17. 17. Cycles de vie de logiciels<br />17<br />COURS IGL<br />Débat (10 Mns)<br />
  18. 18. Cycles de vie de logiciels<br />18<br />Cours igl<br />Section 2 : Cycle de vie de logiciels<br />
  19. 19. Un procédé logiciel (software process) est un ensemble d’activités conduisant à la production d’un logiciel<br />Ils sont aussi appelés cycle de vie d’un logiciel (SDLC)<br />Un procédé définit les étapes qui le composent ainsi que leur enchaînement<br />Les Cycles de vie de logiciels sont complexes et dépendent fortement des acteurs qui dirigent les activités<br />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)<br />Section 2 – Cycles de vie de logiciels<br />19<br />Cours 2 – Cycle de vie de logiciels<br />Procédé Logiciel<br />
  20. 20. Un modèle de procédé est une abstraction d’un procédé<br />Un modèle décrit le procédé selon une certaine perspective<br />Un procédé logiciel est une application d’un modèle pour un projet spécifique, qui peut inclure une certaine adaptation<br />Section 2 – Cycles de vie de logiciels<br />20<br />Cours 2 – Cycle de vie de logiciels<br />Modèles de procédés<br />
  21. 21. Pour maîtriser les gros projets<br />Pour découper le projet et affecter correctement les tâches<br />Pour anticiper et gérer les risques<br />Section 2 – Cycles de vie de logiciels<br />21<br />Cours 2 – Cycle de vie de logiciels<br />Modèles de procédés – Pourquoi ?<br />
  22. 22. Il existe deux types de modèles de procédés :<br />Section 2 – Cycles de vie de logiciels<br />22<br />Cours 2 – Cycle de vie de logiciels<br />Modèles de procédés<br />
  23. 23. Section 2 – Cycles de vie de logiciels<br />23<br />Cours 2 – Cycle de vie de logiciels<br />Modèles de procédés<br />
  24. 24. Aucun modèle n’est meilleur que l’autre<br />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<br />Section 2 – Cycles de vie de logiciels<br />24<br />Cours 2 – Cycle de vie de logiciels<br />Choix d’un modèle<br />
  25. 25. Cycles de Vie des Logiciels<br />25<br />Cours igl<br />Section 2 : Débat (5 mn)<br /><ul><li>Qu’est-ce qu’un gros projet ?
  26. 26. Comment mesure-t-on un gros projet ?
  27. 27. Pourquoi un modèle de procédé est-il essentiel pour conduire un projet de développement ?</li></li></ul><li>Cycles de vie de logiciels<br />26<br />Cours igl<br />Section 3 : Cycles de vie classiques<br />
  28. 28. L’un des premiers modèles proposés, inspiré du modèle de Royce (1970)<br />Aussi appelé modèle linéaire<br />Le résultat de chaque phase est un ensemble de livrables,<br />Une phase ne peut démarrer que si la précédente est finie<br />Le modèle académique par excellence<br />Section 3 – modèles classiques<br />27<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en cascade<br />
  29. 29. Section 3 – modèles classiques<br />28<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en cascade<br />
  30. 30. Avantages :<br />Facile à utiliser et à comprendre<br />Un procédé structuré pour une équipe inexpérimentée<br />Idéal pour la gestion et le suivi de projets<br />Fonctionne très bien quand la qualité est plus importante que les coûts et les délais<br />Section 3 – modèles classiques<br />29<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en cascade<br />
  31. 31. Inconvénients :<br />Les besoins des clients sont très rarement stables et clairement définis<br />Sensibilité aux nouveaux besoins : refaire tout le procédé<br />Une phase ne peut démarrer que si l’étape précédente est finie<br />Le produit n’est visible qu’à la fin<br />Les risques se décalent vers la fin<br />Très faible implication du client<br />Section 3 – modèles classiques<br />30<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en cascade<br />
  32. 32. Quand l’utiliser ?<br />Quand les besoins sont connus et stables<br />Quand la technologie à utiliser est maîtrisée<br />Lors de la création d’une nouvelle version d’un produit existant<br />Lors du portage d’un produit sur une autre plateforme<br />Section 3 – modèles classiques<br />31<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en cascade<br />
  33. 33. Variante du modèle en cascade qui fait l’accent sur la vérification et la validation<br />Le test du produit se fait en parallèle par rapport aux autres activités<br />Section 3 – modèles classiques<br />32<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en V<br />
  34. 34. Section 3 – modèles classiques<br />33<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en V<br />
  35. 35. Avantages :<br />Met l’accent sur lest tests et la validation et par conséquent, ça accroît la qualité du logiciel<br />Chaque livrable doit être testable<br />Facile à planifier dans une gestion de projets<br />Facile à utiliser<br />Section 3 – modèles classiques<br />34<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en V<br />
  36. 36. Inconvénients :<br />Ne gère pas les activités parallèles<br />Ne gère pas explicitement les changements des spécifications<br />Ne contient pas d’activités d’analyse de risque<br />Section 3 – modèles classiques<br />35<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en V<br />
  37. 37. Quand l’utiliser:<br />Quand le produit à développer à de très hautes exigences de qualité<br />Quand les besoins sont connus à l’avance<br />Les technologies à utiliser sont connues à l’avance<br />Section 3 – modèles classiques<br />36<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en V<br />
  38. 38. Le projet se fait sur plusieurs itérations<br />Les développeurs construisent un prototype selon les attentes du client<br />Le prototype est évalué par le client<br />Le client donne son feedback<br />Les développeurs adaptent le prototype selon les besoins du client<br />Quand le prototype satisfait le client, le code est normalisé selon les standards et les bonnes pratiques<br />Section 3 – modèles classiques<br />37<br />Cours 2 – Cycle de vie de logiciels<br />Prototypage<br />
  39. 39. Section 3 – modèles classiques<br />38<br />Cours 2 – Cycle de vie de logiciels<br />Prototypage<br />
  40. 40. Avantages<br />Implication active du client<br />Le développeur apprend directement du client<br />S’adapte rapidement aux changements des besoins<br />Progrès constant et visible<br />Une grande interaction avec le produit<br />Section 3 – modèles classiques<br />39<br />Cours 2 – Cycle de vie de logiciels<br />Prototypage<br />
  41. 41. Inconvénients<br />Le prototypage implique un code faiblement structuré<br />Degré très faible de maintenabilité<br />Le processus peut ne jamais s’arrêter<br />Très difficile d’établir un planning<br />Section 3 – modèles classiques<br />40<br />Cours 2 – Cycle de vie de logiciels<br />Inconvénients<br />
  42. 42. Quand l’utiliser ?<br />Quand les besoins sont instables et/ou nécessitent des clarifications<br />Peut être utilisé avec le modèle en cascade pour la clarification des besoins<br />Quand des livraisons rapides sont exigées<br />Section 3 – modèles classiques<br />41<br />Cours 2 – Cycle de vie de logiciels<br />Inconvénients<br />
  43. 43. Chaque incrément est une construction partielle du logiciel<br />Trie les spécifications par priorités et les regroupent dans des groupes de spécifications<br />Chaque incrément implémente un ou plusieurs groupes jusqu’à ce que la totalité du produit soit finie<br />Section 3 – modèles classiques<br />42<br />Cours 2 – Cycle de vie de logiciels<br />Modèle Incrémental<br />
  44. 44. Section 3 – modèles classiques<br />43<br />Cours 2 – Cycle de vie de logiciels<br />Modèle Incrémental<br />Incrément 1<br />Incrément 2<br />Incrément N<br />Spécifications<br />Conception<br />Implémentation<br />Tests<br />Spécifications<br />Conception<br />Implémentation<br />Tests<br />Spécifications<br />Conception<br />Implémentation<br />Tests<br />
  45. 45. Avantages<br />Développement de fonctionnalités à risque en premier<br />Chaque incrément donne un produit fonctionnel<br />Le client intervient à la fin de chaque incrément<br />Utiliser l’approche « diviser pour régner »<br />Le client entre en relation avec le produit très tôt<br />Section 3 – modèles classiques<br />44<br />Cours 2 – Cycle de vie de logiciels<br />Modèle Incrémental<br />
  46. 46. Inconvénients<br />Exige une bonne planification et une bonne conception<br />Exige une vision sur le produit fini pour pouvoir le diviser en incréments<br />Le coût total du système peut être cher<br />Section 3 – modèles classiques<br />45<br />Cours 2 – Cycle de vie de logiciels<br />Modèle Incrémental<br />
  47. 47. Quand l’utiliser ?<br />Quand la plupart des spécifications sont connues à l’avances et vont être sujettes à de faibles évolutions<br />Quand on veut rapidement un produit fonctionnel<br />Pour des projets de longues durées<br />Pour des projets impliquant de nouvelles technologies<br />Section 3 – modèles classiques<br />46<br />Cours 2 – Cycle de vie de logiciels<br />Modèle Incrémental<br />
  48. 48. Modèle itératif<br />Des incréments sous forme de cycle<br />À la fin de chaque cycle on détermine les objectifs du cycle suivant<br />Chaque cycle est composé des même activités que du modèle en cascade<br />Inclut l’analyse de risque et le prototypage<br />Section 3 – modèles classiques<br />47<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en spirale<br />
  49. 49. Section 3 – modèles classiques<br />48<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en spirale<br />
  50. 50. Détermination des objectifs<br />En terme de fonctionnalité, de performance, de coût,...etc.<br />Déterminer les alternatives : développer, réutiliser, acheter, sous-traiter…etc.<br />Contraintes : coûts, plannings, … etc.<br />Section 3 – modèles classiques<br />49<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en spirale<br />
  51. 51. Identification et évaluation de risques<br />Etudier les alternatives de développement<br />Identification des risques : technologie non maîtrisées, équipe peu expérimentée, planning trop serré, …etc.<br />Evaluation des risques : voir si les risques peuvent impacter le projet et à quel degré<br />Section 3 – modèles classiques<br />50<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en spirale<br />
  52. 52. Développement et test<br />Contient pratiquement la plupart des activités : conception, codage, test, … etc.<br />Planification de la prochaine itération<br />Un planning de l’itération<br />Un plan de tests<br />Section 3 – modèles classiques<br />51<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en spirale<br />
  53. 53. Avantages<br />Identification rapide des risques<br />Impacts minimaux des risques sur le projet<br />Fonctions critiques développées en premier<br />Feedback rapide du client<br />Une évaluation continue du procédé<br />Section 3 – modèles classiques<br />52<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en spirale<br />
  54. 54. Inconvénients<br />L’évaluation des risques peut prendre beaucoup de temps<br />Le modèle est très complexe<br />La spirale peut s’éterniser<br />Les développeurs doivent être réaffectés pendant les phases de non-développement<br />Les objectifs ne sont pas souvent faciles à formuler<br />Section 3 – modèles classiques<br />53<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en spirale<br />
  55. 55. Quand est-ce que l’utiliser ?<br />Quand le prototypage est exigé<br />Quand le risque du projet est considérable<br />Quand les spécifications ne sont pas stables<br />Pour les nouveaux produits<br />Quand le projet implique de la recherche et de l’investigation<br />Section 3 – modèles classiques<br />54<br />Cours 2 – Cycle de vie de logiciels<br />Modèle en spirale<br />
  56. 56. Cycles de vie de logiciels<br />55<br />Cours igl<br />Section 3 : Débat (15 Mn)<br /><ul><li>Quel est le modèle le plus simple et le plus complexe ?
  57. 57. Quels sont les critères qui définiront quel modèle choisir ?
  58. 58. Quelle est la chose la plus difficile pour un modèle incrémental ou itératif ?</li></li></ul><li>Cycles de vie de logiciels<br />56<br />Cours igl<br />Section 4 : Méthodologies Agiles<br />
  59. 59. Au milieu des années 90, un groupe d’expert en Cycles de vie de logiciels voulaient proposer de nouveaux modèles<br />Les nouveaux modèles sont plus « légers » : moins de documentation et moins de contrôle sur le procédé<br />Ces modèles s’adresse à des projets de petite ou moyenne taille avec une équipe réduite<br />Ces modèles permettent de s’ajuster rapidement aux changements des spécifications tout en garantissant des livraisons fréquentes<br />Ces modèles sont qualifiés de « modèles agiles »<br />Section 4 – méthodes agiles<br />57<br />Cours 2 – Cycle de vie de logiciels<br />Apparition<br />
  60. 60. Section 4 – méthodes agiles<br />58<br />Cours 2 – Cycle de vie de logiciels<br />Principes agiles<br />
  61. 61. INDIVIDUS ET INTERACTIONS AU LIEU DE PROCESSUS ET OUTILS<br />Les collaborateurs sont la clé du succès<br />Les « seniors » échoueront s’ils ne collaborent pas en tant qu’équipe<br />Un bon collaborateur n’est pas un forcément un bon programmeur. C’est quelqu’un qui travaille bien en équipe<br />Une surabondance d’outils est aussi mauvaise que le manque d’outils<br />Démarrer petit et investir peu au démarrage<br />Construire l’équipe c’est plus important que construire l’environnement<br />Section 4 – méthodes agiles<br />59<br />Cours 2 – Cycle de vie de logiciels<br />Principes<br />
  62. 62. LOGICIEL FONCTIONNEL AU LIEU DE DOCUMENTATION MASSIVE<br />Un code sans documentation est un désastre<br />Trop de documents est pire que pas de documents<br />Difficulté à produire et à synchroniser avec le code<br />Souvent les documents sont des « mensonges » formels<br />Le code ne ment jamais sur lui-même<br />Produire toujours des documents aussi courts que possible<br />Section 4 – méthodes agiles<br />60<br />Cours 2 – Cycle de vie de logiciels<br />Principes<br />
  63. 63. COLLABORATION DU CLIENT AU LIEU DE LA NÉGOCIATION DE CONTRATS<br />Très difficile de décrire la totalité du logiciel depuis le début<br />Les projets réussis impliquent les clients d’une manière fréquente et régulière<br />Le client doit avoir un contact direct avec l’équipe de développement<br />Section 4 – méthodes agiles<br />61<br />Cours 2 – Cycle de vie de logiciels<br />Principes<br />
  64. 64. RÉAGIR AUX CHANGEMENTS AU LIEU DE SUIVRE UN PLAN<br />Un logiciel ne peut pas être planifié très loin dans le futur<br />Tout change : technologie, environnement et surtout les besoins<br />Les chefs de projets classiques fonctionnent sur la base de GANTT, PERT et le système de tâches<br />Avec le temps, les diagrammes se dégradent car des tâches s’ajoutent et d’autres deviennent non nécessaires<br />Une meilleure stratégie est de planifier très court (02 semaines à 01 mois)<br />Plannings détaillés pour la semaine à venir, rigoureux pour les trois mois et très vagues au-delà<br />Section 4 – méthodes agiles<br />62<br />Cours 2 – Cycle de vie de logiciels<br />Principes<br />
  65. 65. LES DOUZE PRINCIPES AGILES<br />Toujours satisfaire le client à travers des livraisons rapides et continues<br />Bien accueillir tous les changements même les tardifs<br />Livrer fréquemment un système fonctionnel<br />Les clients et les développeurs doivent collaborer<br />Conduire le projet autour d’équipes motivées<br />La meilleure méthode de faire circuler l’information c’est le contact direct entre collaborateurs<br />La première mesure d’avancement c’est un logiciel fonctionnel<br />Section 4 – méthodes agiles<br />63<br />Cours 2 – Cycle de vie de logiciels<br />Principes<br />
  66. 66. LES DOUZE PRINCIPES AGILES<br />Le développement doit être durable et à un rythme constant<br />La bonne conception et l’excellence technique augmentent l’agilité<br />Simplifier au maximum<br />Les meilleurs architectures, besoins et conceptions proviennent d’équipes qui s’organisent d’elles-mêmes<br />L’équipe s’améliore d’une manière autonome et régulière<br />Section 4 – méthodes agiles<br />64<br />Cours 2 – Cycle de vie de logiciels<br />Principes<br />
  67. 67. Section 4 – méthodes agiles<br />65<br />Cours 2 – Cycle de vie de logiciels<br />Principales méthodologies agiles<br />
  68. 68. eXtreme Programming<br />Créée en 1995 Kent Beck and Ward Cunningham<br />XP est un moyen léger, efficace, à bas risques, flexible, scientifique et amusant de développer des logiciels<br />Destinée à des équipes de moyenne taille avec des spécifications incomplets et / ou vagues<br />Le codage est le noyau de XP<br />Section 4 – méthodes agiles<br />66<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie XP<br />
  69. 69. Section 4 – méthodes agiles<br />67<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie XP - Fondamentaux<br />
  70. 70. Section 4 – méthodes agiles<br />68<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie XP – Principales activités<br />
  71. 71. 1- LE JEU DE PLANNING : <br />Le client et les développeurs décident quoi mettre dans la prochaine livraison en triant les spécifications par priorité<br />L’estimation est la responsabilité du développeur, pas du chef de projet ni du client<br />2 – DE PETITES ET FRÉQUENTES LIVRAISONS :<br />D’abord livrer un système minimaliste puis le faire évoluer à travers des versions à des délais très courts<br />Section 4 – méthodes agiles<br />69<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie XP – Les 12 pratiques<br />
  72. 72. 3- LES MÉTAPHORES<br />Exprimer de manière naturelle et très simples des fonctions du système<br />Le client et les développeurs doivent s’accorder sur les métaphores<br />4 – CONCEPTION SIMPLE<br />Le système doit être conçu de la manière la plus simple possible<br />5 – TESTS<br />Les développeurs rédigent les tests unitaires d’une manière continue, Le client rédige les tests d’acceptation des fonctionnalités,<br />Section 4 – méthodes agiles<br />70<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie XP – Les 12 pratiques<br />
  73. 73. 6 – REFACTORING<br />Les développeurs améliorent continuellement le code tout en veillant à le garder fonctionnel<br />7 – PROGRAMMATION PAR PAIRES<br />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.<br />8 - PROPRIÉTÉ COLLECTIVE<br />N’importe qui peut changer le code n’importe où dans le système à n’importe quel moment<br />9 - 40 HEURES LA SEMAINE<br />Le travail ne doit pas dépasser 40 heures par semaine<br />Section 4 – méthodes agiles<br />71<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie XP – Les 12 pratiques<br />
  74. 74. 10 – intégration continue<br />Construire le système à chaque fois qu’une tâche est terminée.<br />11 – Le client est sur site<br />Le client est tout le temps présent avec l’équipe pour participer et répondre aux questions<br />12 – Les standards de codage<br />À 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<br />Section 4 – méthodes agiles<br />72<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie XP – Les 12 pratiques<br />
  75. 75. Implication active du client<br />Forte réactivité des développeurs<br />Responsabilisation et solidarité de l’équipe<br />Appel aux meilleurs pratiques de développement<br />Souplesse extrême<br />Section 4 – méthodes agiles<br />73<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie XP – Avantages<br />
  76. 76. Demande une certaine maturité des développeurs<br />La programmation par paires n’est toujours pas applicable<br />Difficulté de planifier et de budgétiser un projet<br />Stress dû aux devoir de l’intégration continue et des livraisons fréquentes<br />La faible documentation peut nuire en cas de départ des développeurs<br />Section 4 – méthodes agiles<br />74<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie XP – Inconvénients<br />
  77. 77. 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<br />Utilisé comme méthodologie dans le livre : « Agile Software Developmentt with SCRUM” par K. Schwaber et M.. Beedlle en 2001<br />Section 4 – méthodes agiles<br />75<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie Scrum<br />
  78. 78. Section 4 – méthodes agiles<br />76<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie Scrum - Principes<br />
  79. 79. Section 4 – méthodes agiles<br />77<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie Scrum - Principes<br />
  80. 80. Section 4 – méthodes agiles<br />78<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie Scrum - Principes<br />
  81. 81. Méthode très simple et très efficace<br />Adoptée par les géants du marché : Microsoft, Google, Nokia..<br />Orientée projet contrairement à XP qui est orientée développement<br />Peut inclure d’autres activité venant d’autres méthodologies (surtout XP)<br />Section 4 – méthodes agiles<br />79<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie Scrum - Avantages<br />
  82. 82. N’est pas 100% spécifique au GL<br />Difficulté de budgétiser un projet<br />Section 4 – méthodes agiles<br />80<br />Cours 2 – Cycle de vie de logiciels<br />Méthodologie Scrum - Inconvénients<br />
  83. 83. Cycles de vie de logiciels<br />81<br />Cours igl<br />Section 4 : Débat (10 mns)<br /><ul><li>Quelles sont les différences entre une méthode agile et une méthode classique ?
  84. 84. Quels sont les points forts des méthodes agiles ?
  85. 85. Quels en sont les points faibles ?
  86. 86. Quelle est la différence entre Scrum et XP ?
  87. 87. Est-ce que Scrum et XP peuvent-elles être combinées ?</li></li></ul><li>Cycles de vie de logiciels<br />82<br />Cours igl<br />Section 5 : Processus Unifié (Unified Process / UP)<br />
  88. 88. UP est un modèle de procédé très populaire<br />UP est incrémental et itératif<br />UP a plusieurs implémentation et / ou variation dont la plus célèbre est RUP (Rational Unified Process)<br />Section 5 – méthodologie up<br />83<br />Cours 2 – Cycle de vie de logiciels<br />UP<br />
  89. 89. Section 5 – méthodologie up<br />84<br />Cours 2 – Cycle de vie de logiciels<br />UP – Implémentations<br />
  90. 90. Section 5 – méthodologie up<br />85<br />Cours 2 – Cycle de vie de logiciels<br />UP – Principes<br />
  91. 91. PROCESSUS ITÉRATIF ET INCRÉMENTAL<br />UP est composé de quatre phase : l’analyse de besoins (inception), l’élaboration, la construction et la transition<br />Chaque phase peut être décomposée en plusieurs itérations<br />Chaque itération produit un incrément du produit<br />Section 5 – méthodologie up<br />86<br />Cours 2 – Cycle de vie de logiciels<br />UP - Principes<br />
  92. 92. PROCESSUS BASÉ SUR LES CAS D’UTILISATION<br />Les cas d’utilisation formalisent les spécifications fonctionnelle du produit<br />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<br />Section 5 – méthodologie up<br />87<br />Cours 2 – Cycle de vie de logiciels<br />UP - Principes<br />
  93. 93. PROCESSUS CENTRÉ SUR L’ARCHITECTURE<br />UP supporte plusieurs architectures logicielles<br />La phase d’élaboration fournit l’architecture de l’exécutable<br />Cette architecture est une implémentation partielle qui sert de fondation aux développements futurs<br />Section 5 – méthodologie up<br />88<br />Cours 2 – Cycle de vie de logiciels<br />UP - Principes<br />
  94. 94. PROCESSUS QUI MET L’ACCENT SUR LES RISQUES<br />Identification rapide des risques<br />Traitement des risques dans les premières phases du projet<br />Section 5 – méthodologie up<br />89<br />Cours 2 – Cycle de vie de logiciels<br />UP - Principes<br />
  95. 95. UP est composé de quatre phases principales : analyse de besoins (inception), élaboration, construction et transition<br />Section 5 – méthodologie up<br />90<br />Cours 2 – Cycle de vie de logiciels<br />UP – Cycle de vie<br />
  96. 96. UP est un processus bidimensionnel<br />La phase horizontale représente le temps et les étapes<br />La phase verticale représente les activités<br />Section 5 – méthodologie up<br />91<br />Cours 2 – Cycle de vie de logiciels<br />UP – Cycle de vie<br />
  97. 97. Section 5 – méthodologie up<br />92<br />Cours 2 – Cycle de vie de logiciels<br />UP – Cycle de vie<br />
  98. 98. PHASE D’ANALYSE DE BESOINS (INCEPTION)<br />La plus petite phase et la plus courte<br />Etablit une vision globale du projet<br />Essaye d’identifier les principaux cas d’utilisations<br />Propose une ou plusieurs architectures du système<br />Identifie les risques<br />Etablit un planning préliminaire<br />Peut annuler le projet si l’étape prend trop de temps<br />Section 5 – méthodologie up<br />93<br />Cours 2 – Cycle de vie de logiciels<br />UP – Cycle de vie<br />
  99. 99. PHASE D’ÉLABORATION<br />Capturer la majorité des cas d’utilisation<br />Valider l’architecture du système<br />Eliminer les facteurs de risque<br />Peut décider de ne pas aller au-delà<br />Livrable : prototype exécutable d’architecture<br />Livrable : un planning détaillé et précis sur la phase de construction<br />Section 5 – méthodologie up<br />94<br />Cours 2 – Cycle de vie de logiciels<br />UP – Cycle de vie<br />
  100. 100. PHASE DE CONSTRUCTION<br />La phase la plus longue du projet<br />Le reste du système est développé durant cette phase<br />Chaque itération produit un incrément vers le système final<br />Section 5 – méthodologie up<br />95<br />Cours 2 – Cycle de vie de logiciels<br />UP – Cycle de vie<br />
  101. 101. PHASE DE TRANSITION<br />Le système est déployé chez les utilisateurs<br />Les feedbacks récoltés serviront à améliorer le système<br />Section 5 – méthodologie up<br />96<br />Cours 2 – Cycle de vie de logiciels<br />UP – Cycle de vie<br />
  102. 102. Expression de besoins<br />Recenser les besoins fonctionnels et non fonctionnels du système<br />Le diagramme UML de cas d’utilisation est utilisé pour cette phase<br />Section 5 – méthodologie up<br />97<br />Cours 2 – Cycle de vie de logiciels<br />UP – Activités<br />
  103. 103. Analyse<br />Détaille les besoins en spécifications détaillées<br />Une ébauche de la conception<br />Section 5 – méthodologie up<br />98<br />Cours 2 – Cycle de vie de logiciels<br />UP – Activités<br />
  104. 104. Conception<br />Décide comment sera construit le système durant l’implémentation<br />Définition des sous-systèmes et composants<br />Création d’abstractions de la solution<br />Section 5 – méthodologie up<br />99<br />Cours 2 – Cycle de vie de logiciels<br />UP – Activités<br />
  105. 105. Implémentation<br />Traduire les résultats de la conception en un système opérationnel<br />Livrables : code source, exécutables, …etc.<br />Section 5 – méthodologie up<br />100<br />Cours 2 – Cycle de vie de logiciels<br />UP – Activités<br />
  106. 106. Tests<br />Vérification et validation des résultats de l’implémentation<br />Section 5 – méthodologie up<br />101<br />Cours 2 – Cycle de vie de logiciels<br />UP – Activités<br />
  107. 107. Méthodologie complète<br />Identification rapide des risques<br />Largement adoptée en entreprise<br />Intégration avec UML<br />Séparation concise des phases et des livrables<br />Des formations / livres / tutoriaux disponibles<br />Section 5 – méthodologie up<br />102<br />Cours 2 – Cycle de vie de logiciels<br />UP – Avantages<br />
  108. 108. Cycles de vie de logiciels<br />103<br />Cours igl<br />Débat (05 Mns)<br /><ul><li>La méthode UP est-elle une méthode agile ?
  109. 109. C’est une méthode bidimensionnelle, pourquoi ?
  110. 110. C’est une méthode itérative et incrémentale, pourquoi ?
  111. 111. Pourquoi est-elle largement adoptée à votre avis ?</li></li></ul><li>Cycles de vie de logiciels<br />104<br />Cours igl<br />Section 6 : Outils de supports (CASE – Computer-Aided Software Engineering)<br />
  112. 112. CASE est un nom donné aux logiciels utilisés dans les différentes activités de GL (besoins, conception,…)<br />Exemples : compilateurs, éditeurs, débogueurs, …etc.<br />Le but des outils CASE est d’automatiser les tâches et / ou gérer le projet de développement<br />Outils case<br />105<br />Cours 2 – Cycle de vie de logiciels<br />Introduction<br />
  113. 113. Le développement est essentiellement basé sur l’intelligence humaine, là, les outils CASE ne peuvent pas trop intervenir<br />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.<br />Outils case<br />106<br />Cours 2 – Cycle de vie de logiciels<br />Limite des CASE<br />
  114. 114. Les outils CASE peuvent être classés :<br />D’un point de vue fonctionnel : selon la fonction de l’outil.<br />D’un point de vue activité : selon les activités dans lesquelles intervient l’outil<br />Outils case<br />107<br />Cours 2 – Cycle de vie de logiciels<br />Classification des CASE<br />
  115. 115. Outils case<br />108<br />Cours 2 – Cycle de vie de logiciels<br />Classification fonctionnelle<br />
  116. 116. Outils case<br />109<br />Cours 2 – Cycle de vie de logiciels<br />Classification fonctionnelle<br />
  117. 117. Cycles de vie de logiciels<br />110<br />Cours igl<br />Démonstration : outil de génération de documents<br />
  118. 118. Cycles de vie de logiciels<br />111<br />Cours igl<br />Démonstration : outil de gestion de tests unitaires<br />
  119. 119. Cycles de vie de logiciels<br />112<br />Cours igl<br />Démonstration : outil de gestion de tests unitaires<br />
  120. 120. Cycles de vie de logiciels<br />113<br />Cours igl<br />Débat (05 Mns)<br /><ul><li>Quels sont les outils CASE avec lesquels vous avez déjà travaillé ?
  121. 121. Quels sont ceux que vous souhaiteriez découvrir ?</li></li></ul><li>Software Engineering Right Edition, Ian Sommerville, Addison Wesley, 2007<br />Software Development and Professional Practice, John Dooley, APress, 2010<br />Software Development Life Cycle (SDLC), Togi Berra, course session 2<br />Rational Unified Process - Best Practices for Software<br />Development Teams, IBM / Rational, 1998<br />bibliographie<br />114<br />Cours 2 – Cycle de vie de logiciels<br />Bibliographie<br />

×