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 ...
Próxima SlideShare
Cargando en…5
×

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

54.956 visualizaciones

Publicado el

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

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 />

×