COURS 2 CYCLES DE VIE DE LOGICIELS

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,