COURS 2 CYCLES DE VIE DE LOGICIELS
|
|
- Pauline Lavallée
- il y a 8 ans
- Total affichages :
Transcription
1 COURS IGL COURS 2 CYCLES DE VIE DE LOGICIELS Cours 2 : Cycles de vie de Mostefai Mohammed Amine m_mostefai@esi.dz Batata Sofiane s_batata@esi.dz 1
2 O B J EC T I F S DU C O U RS Objectifs du cours Découvrir les principales activités de développement de Connaître les cycles de vie (SDLC) et leur motivation Connaître les SDLC classiques et les méthodes agiles Pourvoir choisir un SDLC sur la base des données concernant un projet de développement Prise de contact avec la méthodologie UP Découvrir les outils de support (CASE) 2
3 Section 1 : Activités de développement Section 3 : Modèles de procédés classiques Section 2 : Cycle de vie Section 4 : Méthodes Agiles INTRODUCTION AU GÉNIE LOGICIEL Cours 2 Cycles de vie de Section 5 : Méthodologie UP Section 6 : Outils de support (CASE) 3
4 COURS IGL Section 1 : Activités de développement Cycles de vie de 4
5 S EC T I O N 1 - I N T RO D U C T I O N Etapes de développement Tout logiciel passe par plusieurs étapes pour être développé Ces étapes peuvent être résumées dans les étapes cidessous : Définition Développement Support 5
6 S EC T I O N 1 - I N T RO D U C T I O N Définition Définir les besoins : Que doit faire le logiciel De quelle façon Et sous quelles conditions 6
7 S EC T I O N 1 - I N T RO D U C T I O N Développement Transformation des données collectées pendant l étape de définition en plusieurs produits : Logiciel fonctionnel Code source Produits connexes 7
8 S EC T I O N 1 - I N T RO D U C T I O N Support Correction Prévention Changements Adaptation Amélioration 8
9 S EC T I O N 1 - I N T RO D U C T I O N Support Correction : réparation des fonctions qui ne marchent pas ou qui ne marchent pas comme souhaité. Adaptation : adaptation de fonctions aux évolutions technologiques actuelles. Amélioration : en terme de performance, ergonomie, Prévention : Rendre le logiciel plus facile à la maintenance 9
10 S EC T I O N 1 - I N T RO D U C T I O N Activités Chaque projet de développement est composé de plusieurs activités Chaque activité est conduite et réalisée par plusieurs acteurs Une activité a des entrées et des sorties. Les livrables font partie des sorties des activités, Les livrables sont des produits ou des documents produits par une activités et utilisé par les activités qui en dépendent Par exemple : document, planning, code source sont tous des livrables 10
11 S EC T I O N 1 - I N T RO D U C T I O N Principales activités Tous les projets de développement ont des activités communes Analyse de besoins Codage Conception Tests Maintenance 11
12 S EC T I O N 1 - I N T RO D U C T I O N Analyse de besoins Conditions qui doivent être respectées par un nouveau produit ou un produit altéré Aussi appelé spécifications Dans les grands projets (par exemple projets nationaux), c est composé d un cahier de charges Cette phase est difficile car le client et les développeurs ne parlent pas le même langage Le livrable de cette phase est un document de spécification 12
13 S EC T I O N 1 - I N T RO D U C T I O N Conception La conception utilise les spécifications pour décider les solutions relatives au différents problèmes de développement La conception décide aussi d un planning de la solution La conception décide de l architecture de la solution Si le produit est centré sur l utilisateur, la conception propose une ébauche de l interface utilisateur 13
14 S EC T I O N 1 - I N T RO D U C T I O N Codage Le codage est une activité très importante du GL Le codage transforme les solutions proposées lors de la conception en un code opérationnel 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. Les techniques de codage dépendent intrinsèquement du langage de programmation utilisé et du paradigme. 14
15 S EC T I O N 1 - I N T RO D U C T I O N Tests Les tests déterminent la qualité du logiciel Les tests déterminent si le logiciel fait ce qu on attend de lui par rapport aux spécifications Plusieurs types de test dont deux principaux : tests unitaires et tests d acceptation 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 Les tests d acceptation vérifient les attentes d un produit logiciel 15
16 S EC T I O N 1 - I N T RO D U C T I O N Maintenance La maintenance consiste à modifier le produit (le logiciel) après sa livraison au client Son but est correctif ou évolutif La maintenance a deux facettes : organisationnelle et technique L aspect organisationnel concerne l organisation des équipes pour une réactivité face aux changements L aspect technique concerne une maintenance sans impact négatif sur le produit Le degré de maintenance dépend de la qualité de la conception 16
17 COURS IGL Débat (10 Mns) Cycles de vie de 17
18 COURS IGL Section 2 : Cycle de vie de Cycles de vie de 18
19 S EC T I O N 2 C YC L ES D E V I E D E LO G I C I E L S Procédé Logiciel Un procédé logiciel (software process) est un ensemble d activités conduisant à la production d un logiciel Ils sont aussi appelés cycle de vie d un logiciel (SDLC) Un procédé définit les étapes qui le composent ainsi que leur enchaînement Les Cycles de vie de sont complexes et dépendent fortement des acteurs qui dirigent les activités 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) 19
20 S EC T I O N 2 C YC L ES D E V I E D E LO G I C I E L S Modèles de procédés Un modèle de procédé est une abstraction d un procédé Un modèle décrit le procédé selon une certaine perspective Un procédé logiciel est une application d un modèle pour un projet spécifique, qui peut inclure une certaine adaptation 20
21 S EC T I O N 2 C YC L ES D E V I E D E LO G I C I E L S Modèles de procédés Pourquoi? Pour maîtriser les gros projets Pour découper le projet et affecter correctement les tâches Pour anticiper et gérer les risques 21
22 S EC T I O N 2 C YC L ES D E V I E D E LO G I C I E L S Modèles de procédés Il existe deux types de modèles de procédés : Méthodes classiques Méthodologie agiles 22
23 S EC T I O N 2 C YC L ES D E V I E D E LO G I C I E L S Modèles de procédés Caractéristiques Méthodes classiques Modèles stricts Etapes très clairement définies Documentation très fournie Fonctionne bien avec les gros projets et les projets gouvernementaux Méthodologies agiles Modèles incrémentaux et itératifs Petites et fréquentes livraisons Accent sur le code et moins sur la documentation Convient aux projets de petite et moyenne taille 23
24 S EC T I O N 2 C YC L ES D E V I E D E LO G I C I E L S Choix d un modèle Aucun modèle n est meilleur que l autre 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 24
25 Section 2 : Débat (5 mn) 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? COURS IGL Cycles de Vie des Logiciels 25
26 COURS IGL Section 3 : Cycles de vie classiques Cycles de vie de 26
27 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en cascade L un des premiers modèles proposés, inspiré du modèle de Royce (1970) Aussi appelé modèle linéaire Le résultat de chaque phase est un ensemble de livrables, Une phase ne peut démarrer que si la précédente est finie Le modèle académique par excellence 27
28 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en cascade 28
29 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en cascade Avantages : Facile à utiliser et à comprendre Un procédé structuré pour une équipe inexpérimentée Idéal pour la gestion et le suivi de projets Fonctionne très bien quand la qualité est plus importante que les coûts et les délais 29
30 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en cascade Inconvénients : Les besoins des clients sont très rarement stables et clairement définis Sensibilité aux nouveaux besoins : refaire tout le procédé Une phase ne peut démarrer que si l étape précédente est finie Le produit n est visible qu à la fin Les risques se décalent vers la fin Très faible implication du client 30
31 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en cascade Quand l utiliser? Quand les besoins sont connus et stables Quand la technologie à utiliser est maîtrisée Lors de la création d une nouvelle version d un produit existant Lors du portage d un produit sur une autre plateforme 31
32 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en V Variante du modèle en cascade qui fait l accent sur la vérification et la validation Le test du produit se fait en parallèle par rapport aux autres activités 32
33 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en V 33
34 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en V Avantages : Met l accent sur lest tests et la validation et par conséquent, ça accroît la qualité du logiciel Chaque livrable doit être testable Facile à planifier dans une gestion de projets Facile à utiliser 34
35 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en V Inconvénients : Ne gère pas les activités parallèles Ne gère pas explicitement les changements des spécifications Ne contient pas d activités d analyse de risque 35
36 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en V Quand l utiliser: Quand le produit à développer à de très hautes exigences de qualité Quand les besoins sont connus à l avance Les technologies à utiliser sont connues à l avance 36
37 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Prototypage Le projet se fait sur plusieurs itérations Les développeurs construisent un prototype selon les attentes du client Le prototype est évalué par le client Le client donne son feedback Les développeurs adaptent le prototype selon les besoins du client Quand le prototype satisfait le client, le code est normalisé selon les standards et les bonnes pratiques 37
38 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Prototypage Ecouter le client Evaluer le prototype Développer le prototype 38
39 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Prototypage Avantages Implication active du client Le développeur apprend directement du client S adapte rapidement aux changements des besoins Progrès constant et visible Une grande interaction avec le produit 39
40 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Inconvénients Inconvénients Le prototypage implique un code faiblement structuré Degré très faible de maintenabilité Le processus peut ne jamais s arrêter Très difficile d établir un planning 40
41 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Inconvénients Quand l utiliser? Quand les besoins sont instables et/ou nécessitent des clarifications Peut être utilisé avec le modèle en cascade pour la clarification des besoins Quand des livraisons rapides sont exigées 41
42 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle Incrémental Chaque incrément est une construction partielle du logiciel Trie les spécifications par priorités et les regroupent dans des groupes de spécifications Chaque incrément implémente un ou plusieurs groupes jusqu à ce que la totalité du produit soit finie 42
43 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle Incrémental Spécifications Conception Implémentation Tests Spécifications Conception Implémentation Tests Incrément 1 Incrément 2 Spécifications Conception Implémentation Tests Incrément N 43
44 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle Incrémental Avantages Développement de fonctionnalités à risque en premier Chaque incrément donne un produit fonctionnel Le client intervient à la fin de chaque incrément Utiliser l approche «diviser pour régner» Le client entre en relation avec le produit très tôt 44
45 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle Incrémental Inconvénients Exige une bonne planification et une bonne conception Exige une vision sur le produit fini pour pouvoir le diviser en incréments Le coût total du système peut être cher 45
46 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle Incrémental Quand l utiliser? Quand la plupart des spécifications sont connues à l avances et vont être sujettes à de faibles évolutions Quand on veut rapidement un produit fonctionnel Pour des projets de longues durées Pour des projets impliquant de nouvelles technologies 46
47 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en spirale Modèle itératif Des incréments sous forme de cycle À la fin de chaque cycle on détermine les objectifs du cycle suivant Chaque cycle est composé des même activités que du modèle en cascade Inclut l analyse de risque et le prototypage 47
48 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en spirale 48
49 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en spirale Détermination des objectifs En terme de fonctionnalité, de performance, de coût,...etc. Déterminer les alternatives : développer, réutiliser, acheter, sous-traiter etc. Contraintes : coûts, plannings, etc. 49
50 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en spirale Identification et évaluation de risques Etudier les alternatives de développement Identification des risques : technologie non maîtrisées, équipe peu expérimentée, planning trop serré, etc. Evaluation des risques : voir si les risques peuvent impacter le projet et à quel degré 50
51 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en spirale Développement et test Contient pratiquement la plupart des activités : conception, codage, test, etc. Planification de la prochaine itération Un planning de l itération Un plan de tests 51
52 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en spirale Avantages Identification rapide des risques Impacts minimaux des risques sur le projet Fonctions critiques développées en premier Feedback rapide du client Une évaluation continue du procédé 52
53 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en spirale Inconvénients L évaluation des risques peut prendre beaucoup de temps Le modèle est très complexe La spirale peut s éterniser Les développeurs doivent être réaffectés pendant les phases de non-développement Les objectifs ne sont pas souvent faciles à formuler 53
54 S EC T I O N 3 M O D È L ES C L A S S I Q U ES Modèle en spirale Quand est-ce que l utiliser? Quand le prototypage est exigé Quand le risque du projet est considérable Quand les spécifications ne sont pas stables Pour les nouveaux produits Quand le projet implique de la recherche et de l investigation 54
55 Section 3 : Débat (15 Mn) Quel est le modèle le plus simple et le plus complexe? 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? COURS IGL Cycles de vie de 55
56 COURS IGL Section 4 : Méthodologies Agiles Cycles de vie de 56
57 S EC T I O N 4 M É T H O D ES AGILES Apparition Au milieu des années 90, un groupe d expert en Cycles de vie de voulaient proposer de nouveaux modèles Les nouveaux modèles sont plus «légers» : moins de documentation et moins de contrôle sur le procédé Ces modèles s adresse à des projets de petite ou moyenne taille avec une équipe réduite Ces modèles permettent de s ajuster rapidement aux changements des spécifications tout en garantissant des livraisons fréquentes Ces modèles sont qualifiés de «modèles agiles» 57
58 S EC T I O N 4 M É T H O D ES AGILES Principes agiles Individus et interactions au lieu de processus et outils Collaboration du client au lieu de négociation de contrats Logiciel fonctionnel au lieu de documentation massive Réagir au changements au lieu de suivre le plan 58
59 S EC T I O N 4 M É T H O D ES AGILES Principes INDIVIDUS ET INTERACTIONS AU LIEU DE PROCESSUS ET OUTILS Les collaborateurs sont la clé du succès Les «seniors» échoueront s ils ne collaborent pas en tant qu équipe Un bon collaborateur n est pas un forcément un bon programmeur. C est quelqu un qui travaille bien en équipe Une surabondance d outils est aussi mauvaise que le manque d outils Démarrer petit et investir peu au démarrage Construire l équipe c est plus important que construire l environnement 59
60 S EC T I O N 4 M É T H O D ES AGILES Principes LOGICIEL FONCTIONNEL AU LIEU DE DOCUMENTATION MASSIVE Un code sans documentation est un désastre Trop de documents est pire que pas de documents Difficulté à produire et à synchroniser avec le code Souvent les documents sont des «mensonges» formels Le code ne ment jamais sur lui-même Produire toujours des documents aussi courts que possible 60
61 S EC T I O N 4 M É T H O D ES AGILES Principes COLLABORATION DU CLIENT AU LIEU DE LA NÉGOCIATION DE CONTRATS Très difficile de décrire la totalité du logiciel depuis le début Les projets réussis impliquent les clients d une manière fréquente et régulière Le client doit avoir un contact direct avec l équipe de développement 61
62 S EC T I O N 4 M É T H O D ES AGILES Principes RÉAGIR AUX CHANGEMENTS AU LIEU DE SUIVRE UN PLAN Un logiciel ne peut pas être planifié très loin dans le futur Tout change : technologie, environnement et surtout les besoins Les chefs de projets classiques fonctionnent sur la base de GANTT, PERT et le système de tâches Avec le temps, les diagrammes se dégradent car des tâches s ajoutent et d autres deviennent non nécessaires Une meilleure stratégie est de planifier très court (02 semaines à 01 mois) Plannings détaillés pour la semaine à venir, rigoureux pour les trois mois et très vagues au-delà 62
63 S EC T I O N 4 M É T H O D ES AGILES Principes LES DOUZE PRINCIPES AGILES 1. Toujours satisfaire le client à travers des livraisons rapides et continues 2. Bien accueillir tous les changements même les tardifs 3. Livrer fréquemment un système fonctionnel 4. Les clients et les développeurs doivent collaborer 5. Conduire le projet autour d équipes motivées 6. La meilleure méthode de faire circuler l information c est le contact direct entre collaborateurs 7. La première mesure d avancement c est un logiciel fonctionnel 63
64 S EC T I O N 4 M É T H O D ES AGILES Principes LES DOUZE PRINCIPES AGILES 8. Le développement doit être durable et à un rythme constant 9. La bonne conception et l excellence technique augmentent l agilité 10. Simplifier au maximum 11. Les meilleurs architectures, besoins et conceptions proviennent d équipes qui s organisent d elles-mêmes 12. L équipe s améliore d une manière autonome et régulière 64
65 S EC T I O N 4 M É T H O D ES AGILES Principales méthodologies agiles Adaptive Software Development (ASD) Dynamic Software Development Method (DSDM) Feature Driven Development (FDD) Rapid Application Development (RAD) Crystal Clear Scrum Extreme Programming (XP) 65
66 S EC T I O N 4 M É T H O D ES AGILES Méthodologie XP extreme Programming Créée en 1995 Kent Beck and Ward Cunningham XP est un moyen léger, efficace, à bas risques, flexible, scientifique et amusant de développer des Destinée à des équipes de moyenne taille avec des spécifications incomplets et / ou vagues Le codage est le noyau de XP 66
67 S EC T I O N 4 M É T H O D ES AGILES Méthodologie XP - Fondamentaux Implication massive du client Programmation par paires Test unitaire continu (TDD) Itérations courtes et livraisons fréquentes 67
68 S EC T I O N 4 M É T H O D ES AGILES Méthodologie XP Principales activités Codage (noyau de XP) Ecoute (le client ou le partenaire) Tests (pendant le codage) Conception (encore basée sur le codage) 68
69 S EC T I O N 4 M É T H O D ES AGILES Méthodologie XP Les 12 pratiques 1- LE JEU DE PLANNING : Le client et les développeurs décident quoi mettre dans la prochaine livraison en triant les spécifications par priorité L estimation est la responsabilité du développeur, pas du chef de projet ni du client 2 DE PETITES ET FRÉQUENTES LIVRAISONS : D abord livrer un système minimaliste puis le faire évoluer à travers des versions à des délais très courts 69
70 S EC T I O N 4 M É T H O D ES AGILES Méthodologie XP Les 12 pratiques 3- LES MÉTAPHORES Exprimer de manière naturelle et très simples des fonctions du système Le client et les développeurs doivent s accorder sur les métaphores 4 CONCEPTION SIMPLE Le système doit être conçu de la manière la plus simple possible 5 TESTS Les développeurs rédigent les tests unitaires d une manière continue, Le client rédige les tests d acceptation des fonctionnalités, 70
71 S EC T I O N 4 M É T H O D ES AGILES Méthodologie XP Les 12 pratiques 6 REFACTORING Les développeurs améliorent continuellement le code tout en veillant à le garder fonctionnel 7 PROGRAMMATION PAR PAIRES 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. 8 - PROPRIÉTÉ COLLECTIVE N importe qui peut changer le code n importe où dans le système à n importe quel moment 9-40 HEURES LA SEMAINE Le travail ne doit pas dépasser 40 heures par semaine 71
72 S EC T I O N 4 M É T H O D ES AGILES Méthodologie XP Les 12 pratiques 10 intégration continue Construire le système à chaque fois qu une tâche est terminée. 11 Le client est sur site Le client est tout le temps présent avec l équipe pour participer et répondre aux questions 12 Les standards de codage À 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 72
73 S EC T I O N 4 M É T H O D ES AGILES Méthodologie XP Avantages Implication active du client Forte réactivité des développeurs Responsabilisation et solidarité de l équipe Appel aux meilleurs pratiques de développement Souplesse extrême 73
74 S EC T I O N 4 M É T H O D ES AGILES Méthodologie XP Inconvénients Demande une certaine maturité des développeurs La programmation par paires n est toujours pas applicable Difficulté de planifier et de budgétiser un projet Stress dû aux devoir de l intégration continue et des livraisons fréquentes La faible documentation peut nuire en cas de départ des développeurs 74
75 S EC T I O N 4 M É T H O D ES AGILES Méthodologie Scrum 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 Utilisé comme méthodologie dans le livre : «Agile Software Developmentt with SCRUM par K. Schwaber et M.. Beedlle en
76 S EC T I O N 4 M É T H O D ES AGILES Méthodologie Scrum - Principes Simple Peut être combiné avec d autres méthodes Compatible avec les best practices Techniques simples Sprints de 2 à 4 semaines Besoins capturés en tant que user stories Empirique Itérations courtes (sprints) Feedback continu Equipes Auto-organisation Multi-compétences Optimisation Détection rapide des anomalies Organisation simple Requiert l ouverture et la visibilité 76
77 S EC T I O N 4 M É T H O D ES AGILES Méthodologie Scrum - Principes 77
78 S EC T I O N 4 M É T H O D ES AGILES Méthodologie Scrum - Principes Processus Sprint Backlog Product Backlog Sprint Backlog Equipe Srum Master Product Owner Team Users and stakeholders Réunions Scrum quotidien Planning Revue Rétrospective Suivi Rapports Vélocité 78
79 S EC T I O N 4 M É T H O D ES AGILES Méthodologie Scrum - Avantages Méthode très simple et très efficace Adoptée par les géants du marché : Microsoft, Google, Nokia.. Orientée projet contrairement à XP qui est orientée développement Peut inclure d autres activité venant d autres méthodologies (surtout XP) 79
80 S EC T I O N 4 M É T H O D ES AGILES Méthodologie Scrum - Inconvénients N est pas 100% spécifique au GL Difficulté de budgétiser un projet 80
81 Section 4 : Débat (10 mns) Quelles sont les différences entre une méthode agile et une méthode classique? 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? COURS IGL Cycles de vie de 81
82 COURS IGL Section 5 : Processus Unifié (Unified Process / UP) Cycles de vie de 82
83 S EC T I O N 5 M É T H O D O LO G I E U P UP UP est un modèle de procédé très populaire UP est incrémental et itératif UP a plusieurs implémentation et / ou variation dont la plus célèbre est RUP (Rational Unified Process) 83
84 S EC T I O N 5 M É T H O D O LO G I E U P UP Implémentations RUP (Rational Unified Process) Enterprise Unified Process (EUP), une extension de RUP Agile Unified Process (AUP) par Scott W. Ambler Essential Unified Process (EssUP), une légère variation Basic Unified Process (BUP) par IBM Open Unified Process (OpenUP) par Eclipse Oracle Unified Method (OUM), 84
85 S EC T I O N 5 M É T H O D O LO G I E U P UP Principes Processus itératif et incrémental Basé sur les cas d utilisation Centré sur l architecture Accent sur les risques 85
86 S EC T I O N 5 M É T H O D O LO G I E U P UP - Principes PROCESSUS ITÉRATIF ET INCRÉMENTAL UP est composé de quatre phase : l analyse de besoins (inception), l élaboration, la construction et la transition Chaque phase peut être décomposée en plusieurs itérations Chaque itération produit un incrément du produit 86
87 S EC T I O N 5 M É T H O D O LO G I E U P UP - Principes PROCESSUS BASÉ SUR LES CAS D UTILISATION Les cas d utilisation formalisent les spécifications fonctionnelle du produit 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 87
88 S EC T I O N 5 M É T H O D O LO G I E U P UP - Principes PROCESSUS CENTRÉ SUR L ARCHITECTURE UP supporte plusieurs architectures logicielles La phase d élaboration fournit l architecture de l exécutable Cette architecture est une implémentation partielle qui sert de fondation aux développements futurs 88
89 S EC T I O N 5 M É T H O D O LO G I E U P UP - Principes PROCESSUS QUI MET L ACCENT SUR LES RISQUES Identification rapide des risques Traitement des risques dans les premières phases du projet 89
90 S EC T I O N 5 M É T H O D O LO G I E U P UP Cycle de vie UP est composé de quatre phases principales : analyse de besoins (inception), élaboration, construction et transition 90
91 S EC T I O N 5 M É T H O D O LO G I E U P UP Cycle de vie UP est un processus bidimensionnel La phase horizontale représente le temps et les étapes La phase verticale représente les activités 91
92 S EC T I O N 5 M É T H O D O LO G I E U P UP Cycle de vie 92
93 S EC T I O N 5 M É T H O D O LO G I E U P UP Cycle de vie PHASE D ANALYSE DE BESOINS (INCEPTION) La plus petite phase et la plus courte Etablit une vision globale du projet Essaye d identifier les principaux cas d utilisations Propose une ou plusieurs architectures du système Identifie les risques Etablit un planning préliminaire Peut annuler le projet si l étape prend trop de temps 93
94 S EC T I O N 5 M É T H O D O LO G I E U P UP Cycle de vie PHASE D ÉLABORATION Capturer la majorité des cas d utilisation Valider l architecture du système Eliminer les facteurs de risque Peut décider de ne pas aller au-delà Livrable : prototype exécutable d architecture Livrable : un planning détaillé et précis sur la phase de construction 94
95 S EC T I O N 5 M É T H O D O LO G I E U P UP Cycle de vie PHASE DE CONSTRUCTION La phase la plus longue du projet Le reste du système est développé durant cette phase Chaque itération produit un incrément vers le système final 95
96 S EC T I O N 5 M É T H O D O LO G I E U P UP Cycle de vie PHASE DE TRANSITION Le système est déployé chez les utilisateurs Les feedbacks récoltés serviront à améliorer le système 96
97 S EC T I O N 5 M É T H O D O LO G I E U P UP Activités Expression de besoins Recenser les besoins fonctionnels et non fonctionnels du système Le diagramme UML de cas d utilisation est utilisé pour cette phase 97
98 S EC T I O N 5 M É T H O D O LO G I E U P UP Activités Analyse Détaille les besoins en spécifications détaillées Une ébauche de la conception 98
99 S EC T I O N 5 M É T H O D O LO G I E U P UP Activités Conception Décide comment sera construit le système durant l implémentation Définition des sous-systèmes et composants Création d abstractions de la solution 99
100 S EC T I O N 5 M É T H O D O LO G I E U P UP Activités Implémentation Traduire les résultats de la conception en un système opérationnel Livrables : code source, exécutables, etc. 100
101 S EC T I O N 5 M É T H O D O LO G I E U P UP Activités Tests Vérification et validation des résultats de l implémentation 101
102 S EC T I O N 5 M É T H O D O LO G I E U P UP Avantages Méthodologie complète Identification rapide des risques Largement adoptée en entreprise Intégration avec UML Séparation concise des phases et des livrables Des formations / livres / tutoriaux disponibles 102
103 Débat (05 Mns) La méthode UP est-elle une méthode agile? 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? COURS IGL Cycles de vie de 103
104 Section 6 : Outils de supports (CASE Computer- Aided Software Engineering) COURS IGL Cycles de vie de 104
105 O U T I L S C A S E Introduction CASE est un nom donné aux utilisés dans les différentes activités de GL (besoins, conception, ) Exemples : compilateurs, éditeurs, débogueurs, etc. Le but des outils CASE est d automatiser les tâches et / ou gérer le projet de développement 105
106 O U T I L S C A S E Limite des CASE Le développement est essentiellement basé sur l intelligence humaine, là, les outils CASE ne peuvent pas trop intervenir 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. 106
107 O U T I L S C A S E Classification des CASE Les outils CASE peuvent être classés : D un point de vue fonctionnel : selon la fonction de l outil. D un point de vue activité : selon les activités dans lesquelles intervient l outil 107
108 O U T I L S C A S E Classification fonctionnelle Outil Exemples Références Outils de planification Editeurs Gestion de configuration Outils PERT, outils d estimation, tableurs Editeurs de texte, éditeurs d image, éditeurs de diagrammes Gestion de versions, gestion de builds Microsoft Project, Excel, GanttProject, DotProject vi, bloc notes, GIMP, Photoshop, Visio SVN, CVS, Team Foundation Server, ClearCase Outils de support de procédé Générateurs de code, outils d assistance, IDE Team Foundation Server, Accurev, Enterprise Architect Outils de traitement de langage Compilateurs, interpréteurs, débogueurs 108
109 O U T I L S C A S E Classification fonctionnelle Outil Exemples Références Outils de test Outils de documentation Environnements de tests, outils de tests unitaires Documents de projet, documents de code Junit, Nunit, TestWorks, Bugzilla Word, Open Office, Sandcastle, Doxygen, javadoc 109
110 COURS IGL Démonstration : outil de génération de documents Cycles de vie de 110
111 COURS IGL Démonstration : outil de gestion de tests unitaires Cycles de vie de 111
112 COURS IGL Démonstration : outil de gestion de tests unitaires Cycles de vie de 112
113 Débat (05 Mns) Quels sont les outils CASE avec lesquels vous avez déjà travaillé? Quels sont ceux que vous souhaiteriez découvrir? COURS IGL Cycles de vie de 113
114 B I B L I O G R A P H I E Bibliographie Software Engineering Right Edition, Ian Sommerville, Addison Wesley, 2007 Software Development and Professional Practice, John Dooley, APress, 2010 Software Development Life Cycle (SDLC), Togi Berra, course session 2 Rational Unified Process - Best Practices for Software Development Teams, IBM / Rational,
Génie logiciel (Un aperçu)
(Un aperçu) (sommerville 2010) Laurent Pérochon INRA URH 63122 St Genès Champanelle Laurent.perochon@clermont.inra.fr Ensemble d activités conduisant à la production d un logiciel Sur un échantillon de
Plus en détailLes méthodes itératives. Hugues MEUNIER
Les méthodes itératives Hugues MEUNIER INTRODUCTION. Toute les méthodes ont le même but : la maîtrise du budget, du planning et de la qualité des projets de développement informatique Plusieurs approches
Plus en détailRègles d engagement. Présentation Diapositives Bibliographie Questions Les vertus de la marche
Règles d engagement Présentation Diapositives Bibliographie Questions Les vertus de la marche Plan Rappels sur l agilité Scrum : une implantation de l agilité Scrum ou XP? Conclusion Historique sélectif
Plus en détail25/12/2012 www.toubkalit.ma
25/12/2012 www.toubkalit.ma 1 Définition Exemple des méthodes agiles Valeurs Principes Le cycle itératif et incrémental (Itération/Sprint) Schéma de travail Méthode Scrum. Méthode XP (Extreme programming).
Plus en détailGestion de projet Agile. STS IRIS Module 4.2 - «Gérer et organiser un projet informatique»
Gestion de projet Agile Module 4.2 - «Gérer et organiser un projet informatique» Sommaire Introduction Principes et méthodes Agiles Scrum 2 Introduction Gestion de projet : démarche structurante assurant
Plus en détailConduite de projets SI. Les méthodes «Agiles» N QUAL/1995/3660e ORESYS
Conduite de projets SI Les méthodes «Agiles» N QUAL/1995/3660e ORESYS Agilité : de quoi parle-t-on? Agilité de l entreprise Urbanisme Architectures SOA Agilité du SI ERP Plateformes applicatives agiles
Plus en détailTopologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM
Méthodes agiles & SCRUM 1/ Pourquoi les méthodes agiles? Définition d une méthode agile. Fondamentaux. Quand les utiliser? 2/ SCRUM En quoi est-ce une méthode agile? Sprints et releases. Le Product Owner.
Plus en détailUML est-il soluble dans les méthodes agiles?
Pascal ROQUES Valtech Training UML est-il soluble dans les méthodes agiles? octobre 07 Résumé On entend beaucoup parler actuellement de deux approches ayant l'air fondamentalement opposées : l'approche
Plus en détailMéthodes agiles. www.businessinteractif.com CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS. Jean-Louis Bénard jlb@businessinteractif.
Méthodes agiles www.businessinteractif.com Jean-Louis Bénard jlb@businessinteractif.fr CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS 0 20 mai 2002 Sommaire Méthodes agiles : une réponse à un malaise?
Plus en détailCours Gestion de projet
Cours Gestion de projet Méthodes de conduite de projet Version Date Auteur V1.8 Septembre 2007 Pascal HEYER 1 Méthodes de conduite de projet Ce document est publié sous la licence libre Creative Commons-BY-NC-SA
Plus en détailGESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET
GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET 1 Tianxiao LIU Licence Professionnelle Réseaux & Sécurité Université de Cergy-Pontoise http://depinfo.u-cergy.fr/~tliu/lpg.php PLAN Objectif et
Plus en détailIntroduction au génie logiciel
Introduction au génie logiciel Guillaume Laurent ENSMM 2007 G. Laurent (ENSMM) Introduction au génie logiciel 2007 1 / 36 Plan du cours 1 Problématique du génie logiciel 2 Méthodes de développement logiciel
Plus en détailJean-Pierre Vickoff www.vickoff.com
Techniques du futur Agile Communication - Architecture - Méthode Vers une approche Agile de 3 ème génération Jean-Pierre Vickoff www.vickoff.com Protocole de séance : Précisions techniques immédiates possibles
Plus en détailSéance 1 Méthodologies du génie logiciel
Séance 1 Méthodologies du génie logiciel Objectifs : Histoire du développement du logiciel. La crise du logiciel. Explorer les différentes méthodologies de développement. Comprendre l importance d adopter
Plus en détailbacklog du produit Product Owner
Méthodes agiles : Définition: selon Scott Ambler «Une méthode agile est une approche itérative et incrémentale pour le développement de logiciel, réalisé de manière très collaborative par des équipes responsabilisées
Plus en détailLes méthodes Agiles Introduction. Intervenant : Tremeur Balbous tremeur@agilegardener.com http://www.agilegardener.com/ 04/09/2008
Les méthodes Agiles Introduction Intervenant : Tremeur Balbous tremeur@agilegardener.com http://www.agilegardener.com/ 04/09/2008 Les méthodes Agiles Le contexte Le Manifeste Agile Une tentative de définition
Plus en détailSoyez agile. Dans l industrie du logiciel, la. De plus chaque projet informatique
Soyez agile Dans l industrie du logiciel, la gestion de projet est confrontée à de nombreux défis. Le principal est de pouvoir assurer l adéquation d un produit et de ses fonctionnalités avec les besoins
Plus en détailDéveloppement itératif, évolutif et agile
Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie
Plus en détailLes méthodes Agile. Implication du client Développement itératif et incrémental
Les méthodes Agile Simon ALEXANDRE - CETIC Plan Overview Agile ne signifie pas Agile signifie Objectifs poursuivis Pourquoi les méthodes Agile apparaissent-elles? Principales causes des échecs de projets
Plus en détailGuide de Préparation. EXIN Agile Scrum. Foundation
Guide de Préparation EXIN Agile Scrum Foundation Édition Décembre 2014 Droits d auteur 2014 EXIN Tous droits réservés. Aucune partie de cette publication ne saurait être publiée, reproduite, copiée, entreposée
Plus en détailJean-Pierre Vickoff. 2008 J-P Vickoff
Agilité étendue Jean-Pierre Vickoff 1 Structure de la présentation PUMA Essentiel méthode Agile de 3 ème génération Le mouvement Itératif-Incrémental (Agile) Agilité étendue au SI et PUMA Essentiel Entreprise
Plus en détailLe Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer
Le Processus RUP Database Administrator Project Leader H. Kadima Performance Engineer Release Engineer Analyst Designer / Developer Tester Table des matières 1. De l artisanat à l industrialisation de
Plus en détailMéthodes de développement
1 / 9 Méthodes de développement Méthodes agiles 1 - Introduction... 2 2 -Le manifeste agile et les méthodes agiles... 2 2.1 Le manifeste agile... 2 2.2 Les méthodes agiles... 3 3 - Caractéristiques communes
Plus en détailContact: Yossi Gal, yossi.gal@galyotis.fr, Téléphone: 06 8288-9494
3a-Agiles Gestion de Projet Contact: Yossi Gal, yossi.gal@galyotis.fr, Téléphone: 06 8288-9494 Yossi Gal, Sep/2011 Agiles, Page: 1 Méthodologies Agiles Yossi Gal, Sep/2011 Agiles, Page: 2 Les Méthodes
Plus en détailCHAPITRE 3 : LES METHODES AGILES?
CHAPITRE 3 : LES METHODES AGILES? UE Gestion de Projet Master 1 STIC 2014/2015 Céline Joiron 2 Introduction Après avoir présenté les cycles de vie «classiques» de la gestion de projet L objectif de ce
Plus en détailYassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES
Yassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES Quelques constats Etude du Standish Group Seul 1/3 des projets informatiques sont qualifiés de succès 50 % sont livrés et opérationnels, mais sont sortis du
Plus en détailAlignement avec les métiers par le test fonctionnel et d acceptation en projets agiles
Alignement avec les métiers par le test fonctionnel et d acceptation en projets agiles Laurent PY CEO, Smartesting Laurent.py@smartesting.com @py_laurent www.smartesting.com Guillaume Coquelle Testeur,
Plus en détailArchitecture pragmatique pour la gestion du cycle de vie des applications (ALM)
Architecture pragmatique pour la gestion du cycle de vie des applications (ALM) Concepts Agile appliqués à l architecture et à la conception Jean-Louis Maréchaux jl.marechaux@ca.ibm.com Jean-Louis Maréchaux
Plus en détailRetour d expérience implémentation Scrum / XP
Retour d expérience implémentation Scrum / XP Bruno Orsier Octobre 2008 p.1 Bruno Orsier, Agile Tour 2008 Grenoble Plan Qui sommes nous? Pourquoi Scrum/XP? Historique de la mise en œuvre Bilan Sondage
Plus en détailLes méthodes agiles UM2 2011-2012. 2011-2012 Les méthodes agiles S. Mathon
Les méthodes agiles UM2 2011-2012 1 2 Sommaire Introduction L origine des Méthodes Agiles Le déroulement d un projet Scrum Au démarrage d une version Au démarrage d une itération/sprint Le déroulement
Plus en détailAgilitéet qualité logicielle: une mutation enmarche
Agilitéet qualité logicielle: une mutation enmarche Jean-Paul SUBRA Introduction : le manifeste Agile Manifeste pour le développement Agile de logiciels Nous découvrons comment mieux développer des logiciels
Plus en détailCertification Scrum Master
avec Jeff Sutherland Les méthodes Agiles représentent indéniablement une approche nouvelle et différente dans la conduite de projets. Au lieu de suivre un plan à la lettre en assignant des tâches à une
Plus en détailEclipse Process Framework et Telelogic Harmony/ITSW
Eclipse Process Framework et Telelogic Harmony/ITSW Boris Baldassari 1 Résumé Une introduction à Eclipse Process Framework (EPF) et au processus OpenUP, et comment tirer profit de ces initiatives dans
Plus en détailEXIN Agile Scrum Master
Guide de préparation EXIN Agile Scrum Master Édition de juillet 2015 Copyright 2015 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing
Plus en détailGL - 2 2.2 Processus de développement Cycles de vie
GL - 2 2.2 Processus de développement Cycles de vie Lydie du Bousquet Lydie.du-bousquet@imag.fr En collaboration avec J.-M. Favre, Ph. Lalanda, I. Parissis, Y. Ledru 1 Plan Introduction Modèles en cascade
Plus en détailMéthodes Agiles et gestion de projets
Méthodes Agiles et gestion de projets Eric LELEU Consultant Solutions Collaboratives Contact ericleleu@nordnet.fr Site Personnel http://home.nordnet.fr/~ericleleu Blog http://ericleleu.spaces.live.fr La
Plus en détailLe rôle du coach Agile et son apport pour le projet
Le rôle du coach Agile et son apport pour le projet Franck Beulé Soirée du 4 novembre 2013 Chez Google 45 Sommaire Qu est- ce qu un coach Agile? Que s interdit- il? Ce qu il fait Ses points d anenoon Des
Plus en détailGestion Projet. Cours 3. Le cycle de vie
Gestion Projet Cours 3 Le cycle de vie Sommaire Généralités 3 Séquentiel 7 Itératif/Incrémental 17 Extreme Programming 22 Que choisir? 29 Etats Transverse 33 Cours 3 2006-2007 2 Généralités Cours 3 2006-2007
Plus en détailBut de cette introduction à la gestion de projets :
But de cette introduction à la gestion de projets : Présenter quelques méthodes de conception logicielle. Replacer la conception de bases de données dans un contexte plus vaste. Présenter quelques méthodes
Plus en détailL'agilité appliquée à nous-mêmes. Philippe Krief, PhD Development Manager IBM France Lab
L'agilité appliquée à nous-mêmes Philippe Krief, PhD Development Manager IBM France Lab Agenda Où en était l équipe RPP il y a 24 mois Réorganisation de l équipe et du projet autour de Scrum et de RTC
Plus en détailIntroduction Les processus traditionnels extreme Programming Conclusion. extreme Programming. vers plus d agilité. F. Miller francois.miller@inpg.
vers plus d agilité F. Miller francois.miller@inpg.fr FC INPG Octobre 2008 - version 1.0 Introduction Contexte Le monde bouge économie des moyens (humains, financier,...) ; recherche de plus d efficacité
Plus en détailPlan. 1 Cycles de développement. 2 Méthodes agiles, principes généraux. 3 Comment se passe un Sprint?
Plan nitiation au Génie Logiciel Cours 5 ntroduction au π développement agile T. Genet (genet@irisa.fr) (STC/RSA) GEN-5 1/ 28 T. Genet (genet@irisa.fr) (STC/RSA) GEN-5 2/ 28 Bibliographie Plan L informatique
Plus en détailL enseignement de méthodes agiles dans un contexte d apprentissage actif
L enseignement de méthodes agiles dans un contexte d apprentissage actif Ruben González-Rubio Eugène Morin Balkrishna Sharma Gukhool Groupe ɛ X it C1-3019 Département de génie électrique et de génie informatique
Plus en détailLe génie logiciel. maintenance de logiciels.
Le génie logiciel Définition de l IEEE (IEEE 1990): L application d une approche systématique, disciplinée et quantifiable pour le développement, l opération et la maintenance de logiciels. Introduction
Plus en détailScrum et l'agilité des équipes de développement
NormandyJUG Scrum et l'agilité des équipes de développement Par Dimitri Baeli & Nicolas Giard 23 Février 2010 Présentation des intervenants Dimitri Baeli http://twitter.com/dbaeli VP Quality Enterprise
Plus en détailMéthode Agile de 3 ème génération. 2008 J-P Vickoff
PUMA Essentiel Méthode Agile de 3 ème génération 1 Structure de la présentation PUMA Essentiel méthode Agile de 3 ème génération Quelques principes Agiles Principales pratique Agile de pilotage Structure
Plus en détailAgile Maroc 24 Novembre 2010. Méthodes agiles. Thierry Cros. http://etre-agile.com. Agile Maroc 24 novembre 2010
Agile Maroc 24 Novembre 2010 Méthodes agiles Thierry Cros 1 Thierry Cros 10 ans déjà... 2010 Création Extreme Programming France 2009 SigmaT Les Agilistes Toulousains 2010 Membre de «Fédération Agile»
Plus en détailGESTION DE PROJET : LA METHODE AGILE
GESTION DE PROJET : LA METHODE AGILE Le SCRUM est une méthode de gestion de projet. Elle a pour but d améliorer la productivité des équipes. Ce terme est inspiré du terme Scrum en rugby qui désigne une
Plus en détailDéveloppement ebusiness
Développement ebusiness Cédric Pulrulczyk ( cedric.pulrulczyk@alcatel.fr ) Alcatel Université Lille I March 2005 Plan Analyse des besoins Méthodologie XP Modélisation UML Outil de développement Tests et
Plus en détail1/15. Jean Bernard CRAMPES Daniel VIELLE
1/15 Jean Bernard CRAMPES Daniel VIELLE CaseOnCloud est un SaaS de gestion de projets de développement logiciel CaseOC est : Multi démarches : MACAO MACAO Agile SCRUM Suivi d'aucune démarche particulière
Plus en détailBesoins utilisateurs. Quelle démarche pour passer des besoins au code? Code. chapitre1 UNIFIED MODELING LANGUAGE. package LogiqueMetier.
chapitre1 Besoins utilisateurs Quelle démarche pour passer des besoins au code?? UNIFIED MODELING LANGUAGE package LogiqueMetier.Gestion; import LogiqueMetier.Catalogue.Livre; import java.util.*;public
Plus en détailScrum + Drupal = Julien Dubois
Pourquoi j aime Scrum Pourquoi Scrum et Drupal sont faits pour s entendre Scrum + Drupal = Julien Dubois Happyculture.coop De quoi allons-nous parler? 1. Que sont les méthodes agiles? 2. Présentation de
Plus en détailTP3 Intégration de pratiques agiles. 1. User Stories (1) Scénario d intégration agile. En direct-live du château
Rappel TP3 Intégration de pratiques agiles En direct-live du château 40 41 Scénario d intégration agile 1. User Stories (1) 1. Rédiger les User Stories (exigences) 2. Planifier les Itérations (quoi / quand)
Plus en détailAnalyse et Conception objet du logiciel Analyse et conception objet du logiciel : Méthode de conception objet et notation UML.
Analyse et conception objet du logiciel : Méthode de conception objet et notation UML Rémy Courdier Email : Remy.Courdier@univ-reunion.fr Rémy Courdier V2.1 1 Plan du cours Introduction au Génie Logiciel
Plus en détailConduite de projets informatiques Développement, analyse et pilotage (2ième édition)
Avant-propos 1. Objectifs du livre 13 2. Structure du livre 14 Un projet informatique 1. Les enjeux 17 1.1 Les buts d'un projet 17 1.2 Les protagonistes d'un projet 18 1.3 Exemples de projets 19 2. Les
Plus en détailCours Ephec Niv. 2 : Technique et gestion de projet. Par Monsieur Bertieaux Année Académique 2014-2015. Quelles sont les 4 valeurs Agiles?
Cours Ephec Niv. 2 : Technique et gestion de projet Par Monsieur Bertieaux Année Académique 2014-2015 Réponse aux questions du cours, slide Cours 2_2_Scrum Quelles sont les 4 valeurs Agiles? 1. «Les personnes
Plus en détailL'AGILITÉ AVEC VISUAL STUDIO
CC15080 MICROSOFT Livre Blanc Agilité avec Visual Studio 350x240 31/01/12 08:57 Page1 CC15080 MICROSOFT Livre Blanc Agilité avec Visual Studio 350x240 31/01/12 08:57 Page2 L'AGILITÉ AVEC VISUAL STUDIO
Plus en détail2012-2013. Catalogue des formations. Depuis 15 ans, nous soutenons votre évolution. Leadership et potentiel humain Amélioration des processus
Catalogue des formations 0-0 Depuis ans, nous soutenons votre évolution. Leadership et potentiel humain Amélioration des processus Gestion de projets (PMI) Graphisme et multimédia Technologies Classes
Plus en détailREX Scrum Master du terrain
REX Scrum Master du terrain Ludovic Larché Agile Tour 2012 à Rennes le 4 octobre 2012 Qui suis je? Ludovic LARCHE Agile Scrum / Kanban Consultant Scrum Master depuis 2008 Accompagnement de Product Owner
Plus en détailScrum Une méthode agile pour vos projets
Avant-propos 1. Objectif du livre 17 2. Notre démarche 17 3. Structure du livre 18 4. Remerciements 20 Scrum, une méthode agile avant tout 1. Le grand départ 21 2. La gestion de projet informatique 22
Plus en détailAgile 360 Product Owner Scrum Master
Agile 360 Product Owner Scrum Master Lead Technique Equipe Agile Conception Agile Leadership Agile Software Craftmanship Test Driven Development Catalogue 2013 Liste des formations Formation Agile 360
Plus en détailNe renvoyez pas vos architectes! Utilisez-les avec agilité
Ne renvoyez pas vos architectes! Utilisez-les avec agilité Intégration du travail architectural dans un cycle de développement Agile Jean-Louis Maréchaux jl.marechaux@ca.ibm.com Qui suis-je? Jean-Louis
Plus en détailQualité et Test des Logiciels. Le génie logiciel. Moez Krichen. moez.krichen@gmail.com
ENIS 2010-2011 Le génie logiciel Moez Krichen moez.krichen@gmail.com Cycle de vie du logiciel Une version d'un logiciel correspond à un état donné de l'évolution d'un produit logiciel utilisant le «versionnage»
Plus en détailProcessus d Informatisation
Processus d Informatisation Cheminement de la naissance d un projet jusqu à son terme, deux grandes étapes : Recherche ou étude de faisabilité (en amont) L utilisateur a une idée (plus ou moins) floue
Plus en détailUne bonne dose d'agilité au cœur de votre équipe. La rece e Visual Studio 2012 pour des projets maitrisés
Une bonne dose d'agilité au cœur de votre équipe. La rece e Visual Studio 2012 pour des projets maitrisés Une bonne dose d'agilité au coeur de votre équipe. La recette Visual Studio 2012 pour des projets
Plus en détailLes Méthodes Agiles. description et rapport à la Qualité. Benjamin Joguet Rémi Perrot Guillaume Tourgis
Les Méthodes Agiles description et rapport à la Qualité Benjamin Joguet Rémi Perrot Guillaume Tourgis 1 Plan Présentation générale d'agile Qu'est ce qu'une méthode Agile? Le manifeste Les valeurs Les principes
Plus en détailAGILE Historique et évolution
AGILE Historique et évolution Itératif Incrémental Adaptatif 2 Méthode Agile Historique et évolution AGILE Historique et évolution Itératif et incrémental Les notions sous-jacentes aux principes incrémental
Plus en détailLES OUTILS DE GESTION DE PROJET
LES OUTILS DE GESTION DE PROJET 1 Qu est-ce qu un projet? Quelle est la définition? En quoi diffère-t-il de l activité d une entreprise, d un ensemble de personnes? Listez tous les ingrédients, aspects,
Plus en détailGénie Logiciel. Notes de l an passé-k. Planning Projets. Evolution des approches (1/4) Evolution des approches (2/4) Evolution des approches (3/4)
Noël NOVELLI ; Université d Aix-Marseille; LIF et Département d Informatique Case 901 ; 163 avenue de Luminy 13 288 MARSEILLE cedex 9 Génie Logiciel Notes de l an passé-k Intervenant Laurent TICHIT (617)
Plus en détailIndustrialiser la chaîne complète de fabrication 1ère partie - Les bénéfices de la solution logicielle IBM VisualAge Pacbase / Rational
IBM Software Group Industrialiser la chaîne complète de fabrication 1ère partie - Les bénéfices de la solution logicielle IBM VisualAge Pacbase / Rational Fernard Bonaguidi fernand.bonaguidi@fr.ibm.com
Plus en détailAnalyse,, Conception des Systèmes Informatiques
Analyse,, Conception des Systèmes Informatiques Méthode Analyse Conception Introduction à UML Génie logiciel Définition «Ensemble de méthodes, techniques et outils pour la production et la maintenance
Plus en détailLe Product Owner Clé de voute d un projet agile réussi
Le Product Owner Clé de voute d un projet agile réussi Cédric Pourbaix - EFIDEV Qui est le product owner? SM PO Scrum Team Qui est le product owner? SM PO Scrum Team Qui est le product owner? marketing
Plus en détailEnterprise Scrum Organisation des développements chez exo. Agile Tour Rennes 2010 / 10 / 07
Enterprise Scrum Organisation des développements chez exo Agile Tour Rennes 2010 / 10 / 07 Les Projets et Produits exo Open Source exo JCR exo Portal / GateIn / WebOS exo Social exo Content DMS, WCM, Workflow
Plus en détailRendez-vous la liberté avec Rational Quality Manager
IBM Software Group RAT02 Rendez-vous la liberté avec Rational Quality Manager Bernard Dupré IBM Rational IT Specialist 2008 IBM Corporation Envisager une plateforme qui change la production de logiciels
Plus en détailMéthodologie d ingénierie logicielle adaptée à une PME
Méthodologie d ingénierie logicielle adaptée à une PME Auteur : Thiessoz Yannick Responsable InfoTeam : Beat Ackermann Responsables UNIFR : Jean Hennebert et Patrik Fuhrer Type : Travail de master de l
Plus en détailen SCÈNE RATIONAL Rational Démonstration SDP : automatisation de la chaîne de développement Samira BATAOUCHE sbataouche@fr.ibm.com
Rational Démonstration SDP : automatisation de la chaîne de développement Samira BATAOUCHE sbataouche@fr.ibm.com Fabrice GRELIER fabrice.grelier@fr.ibm.com RATIONAL en SCÈNE 2007 IBM Corporation Objectif
Plus en détailLes méthodes Agiles. Introduc)on aux méthodes Agiles Exemple : Scrum
Les méthodes Agiles Introduc)on aux méthodes Agiles Exemple : Scrum Défini)on de base Les méthodes Agiles sont des procédures de concep)on de logiciel qui se veulent plus pragma)ques que les méthodes tradi)onnelles
Plus en détailCisco Unified Computing Migration and Transition Service (Migration et transition)
Cisco Unified Computing Migration and Transition Service (Migration et transition) Le service Cisco Unified Computing Migration and Transition Service (Migration et transition) vous aide à migrer vos applications
Plus en détailLe rôle de l'analyste d'affaires et la place de la documentation dans un processus Agile
Le rôle de l'analyste d'affaires et la place de la documentation dans un processus Agile François Beauregard (fbeauregard@pyxis-tech.com) 2008 Pyxis Technologies. Tous droits réservés. All Rights Reserved.
Plus en détailPaul FLYE SAINTE MARIE
Paul FLYE SAINTE MARIE ASSISTANT CHEF DE PROJET DANS LE DÉVELOPPEMENT INFORMATIQUE Domaines de compétences Conduite de projet (échange avec la maitrise d ouvrage, maitrise d œuvre, rédaction des spécifications
Plus en détailLes méthodes agiles en développement informatique : Fondements théoriques et retours d expérience
Les méthodes agiles en développement informatique : Fondements théoriques et retours d expérience Sommaire Préface... 3 Introduction... 5 Partie I : Les fondements théoriques... 7 Chapitre I : La méthode
Plus en détailISTQB Agile Tester en quelques mots ISTQB Marketing Working Group
ISTQB Agile Tester en quelques mots ISTQB Marketing Working Group Mai 2014 Qu est-ce que l ISTQB? ISTQB : International Software Testing Qualifications Board (www.istqb.org): Association sans but lucratif
Plus en détailopenarchitectureware & transformation de modèle Yannick Lizzi Architecte Logiciel itemis France Mail: lizzi@itemis.de
openarchitectureware & transformation de modèle Yannick Lizzi Architecte Logiciel itemis France Mail: lizzi@itemis.de itemis France 2009 All rights reserved 1 Itemis en quelques mots Spécialisé dans l
Plus en détailLes Bonnes PRATIQUES DU TEST LOGICIEL
Les Bonnes PRATIQUES DU TEST LOGICIEL SOMMAIRE Qu est-ce que le test logiciel? Pourquoi le test est-il un maillon crucial de l ingénierie logicielle? Quels sont les différents types de tests? Qu est-ce
Plus en détailMéthodologies Orientées-Objet!
MAI NFE103 Année 2013-2014 Méthodologies Orientées-Objet! F.-Y. Villemin (f-yv@cnam.fr) Plan!!Les différentes méthodologies! Démarche! Cycle de vie!!rational Unified Process (RUP)!!La méthode Layman!!Notre
Plus en détailCursus Sage ERP X3 Outils & Développement. Le parcours pédagogique Sage ERP X3 Outils et Développement
Cursus Outils & Développement Vous êtes Consultant, Chef de Projets, Directeur des Systèmes d Information, Directeur Administratif et Financier, Optez pour les «formations Produits» Nous vous proposons
Plus en détailLes Méthodes Agiles. Plan. Lecture. Objectifs du cours
Plan Les Méthodes Agiles Aurélien Tabard Master Informatique Université Claude Bernard Lyon 1 2013 2014 1. Retour rapide sur les méthodes de conception 2. Principes des méthodes Agiles 3. XP : extreme
Plus en détailZ i e d Z a i e r ( 5 1 4 ) 5 8 5-0 2 6 6
Informations personnelles 2900 Chemin de Bedford Apt. 2 Montréal, Québec. H3S 1G6. CANADA Zied Zaier (514) 585-0266 zaier.zied@gmail.com Résumé des compétences - Bon esprit d'analyse et de synthèse - Excellente
Plus en détail1. Considérations sur le développement rapide d'application et les méthodes agiles
Chapitre 1 Introduction 1. Considérations sur le développement rapide d'application et les méthodes agiles 1.1 Rappel Longtemps les méthodes en cascade ou en V ont été opposées aux démarches empiriques
Plus en détailCompte-rendu du petit-déjeuner. Vers l entreprise Agile
Compte-rendu du petit-déjeuner Vers l entreprise Agile 01/04/2014 Intervenants : Ludovic Cinquin Directeur Générale OCTO Technology France lcinquin@octo.com @Lcinquin Hervé Lourdin Lean & Agile Practice
Plus en détailTuesday, October 20, 2009. Nantes
Tuesday, October 20, 2009 Nantes Retour d'expérience SCRUM/XP dans un contexte CMMI-DEV niveau 2 SM CMM Integration, IDEAL, and SCAMPI are service marks of Carnegie Mellon University. Capability Maturity
Plus en détailGestion de projets logiciels. Xavier Dubuc
Gestion de projets logiciels Résumé blocus Xavier Dubuc 16 janvier 2011 1 Table des matières 1 Planification (PERT-GANTT) 3 1.1 Définitions............................................. 3 1.2 Analyse un
Plus en détailLe Processus Unifié. Une Démarche Orientée Modèle. IUP NTIE - Master 1 - Jérémie Guiochet - 4/11/09
Le Processus Unifié Une Démarche Orientée Modèle IUP NTIE - Master 1 - Jérémie Guiochet - 4/11/09 1 Sommaire Partie 1 : UML et processus unifié Partie 2 : Artefacts Partie 3 : Enchaînement d itérations
Plus en détailRetour d expérience. Le rôle du Business Analyst chez Orange. Nadia Magarino & Christophe Dufour 29 avril 2015
Retour d expérience Le rôle du Business Analyst chez Orange Nadia Magarino & Christophe Dufour 29 avril 2015 Plus de 161 000 salariés à votre service mobile entreprises internet et fixe Plus de 161 000
Plus en détailL externalisation de vos logiciels entreprises : une solution aux problèmes de coûts, de sécurités et de réactivités
Bureau Virtuel L externalisation de vos logiciels entreprises : une solution aux problèmes de coûts, de sécurités et de réactivités Que ce soit par la communication, par les échanges ou par la collaboration,
Plus en détailMéthodologies de gestion de projet agiles et en cascade : définition, combinaison et application.
Université de Fribourg, Suisse Département d informatique Systèmes d information Fribourg, mai 2011 Méthodologies de gestion de projet agiles et en cascade : définition, combinaison et application. Cindy
Plus en détailModèle de changement d organisation. Leanpizza.net présente. Petit Guide Rapide du jeu de cartes Modèle de Changement d Organisation
Guide rapide Leanpizza.net présente Petit Guide Rapide du jeu de cartes Modèle de Changement d Organisation v1.0 Rédacteur : Olivier Lafontan Traduction : Yannick Quenec hdu Date : 29 juin 2010 - Guide
Plus en détailYannick Prié Département Informatique Faculté des Sciences et Technologies Université Claude Bernard Lyon 1 2011-2012
Yannick Prié Département Informatique Faculté des Sciences et Technologies Université Claude Bernard Lyon 1 2011-2012 1/3 Méthodes et processus 2/3 Processus unifié 3/3 Méthodes Agile 2011-2012 / Yannick
Plus en détailbasée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML
basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML http://olivier-augereau.com Sommaire Introduction I) Les bases II) Les diagrammes
Plus en détail