SlideShare une entreprise Scribd logo
Cours 2 :Cycles de vie de logicielsCours IGLcours 2Cycles de vie de logiciels1Mostefai Mohammed Amine – m_mostefai@esi.dzBatata Sofiane – s_batata@esi.dz
Découvrir les principales activités de développement de logicielsConnaître les cycles de vie (SDLC) et leur motivationConnaître les SDLC classiques et les méthodes agilesPourvoir choisir un SDLC sur la base des données concernant un projet de développementPrise de contact avec la méthodologie UPDécouvrir les outils de support (CASE)Objectifs du cours2Cours 2 – Cycle de vie de logicielsObjectifs du cours
Cours 2Cycles de vie de logiciels3Introduction au génie logiciel
Cycles de vie de logiciels4Cours iglSection 1 : Activités de développement
Tout logiciel passe par plusieurs étapes pour être développéCes étapes peuvent être résumées dans les étapes ci-dessous :Section 1 - introduction5Cours 2 – Cycle de vie de logicielsEtapes de développement
Définir les besoins :Que doit faire le logicielDe quelle façonEt sous quelles conditionsSection 1 - introduction6Cours 2 – Cycle de vie de logicielsDéfinition
Transformation des données collectées pendant l’étape de définition en plusieurs produits :Logiciel fonctionnelCode sourceProduits connexesSection 1 - introduction7Cours 2 – Cycle de vie de logicielsDéveloppement
Section 1 - introduction8Cours 2 – Cycle de vie de logicielsSupport
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 maintenanceSection 1 - introduction9Cours 2 – Cycle de vie de logicielsSupport
Chaque projet de développement est composé de plusieurs activitésChaque activité est conduite et réalisée par plusieurs acteursUne 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épendentPar exemple : document, planning, code source sont tous des livrablesSection 1 - introduction10Cours 2 – Cycle de vie de logicielsActivités
Tous les projets de développement ont des activités communesSection 1 - introduction11Cours 2 – Cycle de vie de logicielsPrincipales activités
Conditions qui doivent être respectées par un nouveau produit ou un produit altéréAussi appelé spécificationsDans les grands projets (par exemple projets nationaux), c’est composé d’un cahier de chargesCette phase est difficile car le client et les développeurs ne parlent pas le même langageLe livrable de cette phase est un document de spécificationSection 1 - introduction12Cours 2 – Cycle de vie de logicielsAnalyse de besoins
La conception utilise les spécifications pour décider les solutions relatives au différents problèmes de développementLa conception décide aussi d’un planning de la solutionLa conception décide de l’architecture de la solutionSi le produit est centré sur l’utilisateur, la conception propose une ébauche de l’interface utilisateurSection 1 - introduction13Cours 2 – Cycle de vie de logicielsConception
Le codage est une activité très importante du GLLe codage transforme les solutions proposées lors de la conception en un code opérationnelLa 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. Section 1 - introduction14Cours 2 – Cycle de vie de logicielsCodage
Les tests déterminent la qualité du logicielLes tests déterminent si le logiciel fait ce qu’on attend de lui par rapport aux spécificationsPlusieurs types de test dont deux principaux : tests unitaires et tests d’acceptationLes tests unitaires sont orientés code. Ils se rédigent durant l’activité de codage et se revérifient pendant la phase de testLes tests d’acceptation vérifient les attentes d’un produit logicielSection 1 - introduction15Cours 2 – Cycle de vie de logicielsTests
La maintenance consiste à modifier le produit (le logiciel) après sa livraison au clientSon but est correctif ou évolutifLa maintenance a deux facettes : organisationnelle et techniqueL’aspect organisationnel concerne l’organisation des équipes pour une réactivité face aux changementsL’aspect technique concerne une maintenance sans impact négatif sur le produitLe degré de maintenance dépend de la qualité de la conceptionSection 1 - introduction16Cours 2 – Cycle de vie de logicielsMaintenance
Cycles de vie de logiciels17COURS IGLDébat (10 Mns)
Cycles de vie de logiciels18Cours iglSection 2 : Cycle de vie de logiciels
Un procédé logiciel (software process) est un ensemble d’activités conduisant à la production d’un logicielIls 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înementLes Cycles de vie de logiciels sont complexes et dépendent fortement des acteurs qui dirigent les activitésLes 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)Section 2 – Cycles de vie de logiciels19Cours 2 – Cycle de vie de logicielsProcédé Logiciel
Un modèle de procédé est une abstraction d’un procédéUn modèle décrit le procédé selon une certaine perspectiveUn procédé logiciel est une application d’un modèle pour un projet spécifique, qui peut inclure une certaine adaptationSection 2 – Cycles de vie de logiciels20Cours 2 – Cycle de vie de logicielsModèles de procédés
Pour maîtriser les gros projetsPour découper le projet et affecter correctement les tâchesPour anticiper et gérer les risquesSection 2 – Cycles de vie de logiciels21Cours 2 – Cycle de vie de logicielsModèles de procédés – Pourquoi ?
Il existe deux types de modèles de procédés :Section 2 – Cycles de vie de logiciels22Cours 2 – Cycle de vie de logicielsModèles de procédés
Section 2 – Cycles de vie de logiciels23Cours 2 – Cycle de vie de logicielsModèles de procédés
Aucun modèle n’est meilleur que l’autreLe 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’équipeSection 2 – Cycles de vie de logiciels24Cours 2 – Cycle de vie de logicielsChoix d’un modèle
Cycles de Vie des Logiciels25Cours iglSection 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 ?Cycles de vie de logiciels26Cours iglSection 3 : Cycles de vie classiques
L’un des premiers modèles proposés, inspiré du modèle de Royce (1970)Aussi appelé modèle linéaireLe résultat de chaque phase est un ensemble de livrables,Une phase ne peut démarrer que si la précédente est finieLe modèle académique par excellenceSection 3 – modèles classiques27Cours 2 – Cycle de vie de logicielsModèle en cascade
Section 3 – modèles classiques28Cours 2 – Cycle de vie de logicielsModèle en cascade
Avantages :Facile à utiliser et à comprendreUn procédé structuré pour une équipe inexpérimentéeIdéal pour la gestion et le suivi de projetsFonctionne très bien quand la qualité est plus importante que les coûts et les délaisSection 3 – modèles classiques29Cours 2 – Cycle de vie de logicielsModèle en cascade
Inconvénients  :Les besoins des clients sont très rarement stables et clairement définisSensibilité aux nouveaux besoins : refaire tout le procédéUne phase ne peut démarrer que si l’étape précédente est finieLe produit n’est visible qu’à la finLes risques se décalent vers la finTrès faible implication du clientSection 3 – modèles classiques30Cours 2 – Cycle de vie de logicielsModèle en cascade
Quand l’utiliser ?Quand les besoins sont connus et stablesQuand la technologie à utiliser est maîtriséeLors de la création d’une nouvelle version d’un produit existantLors du portage d’un produit sur une autre plateformeSection 3 – modèles classiques31Cours 2 – Cycle de vie de logicielsModèle en cascade
Variante du modèle en cascade qui fait l’accent sur la vérification et la validationLe test du produit se fait en parallèle par rapport aux autres activitésSection 3 – modèles classiques32Cours 2 – Cycle de vie de logicielsModèle en V
Section 3 – modèles classiques33Cours 2 – Cycle de vie de logicielsModèle en V
Avantages :Met l’accent sur lest tests et la validation et par conséquent, ça accroît la qualité du logicielChaque livrable doit être testableFacile à planifier dans une gestion de projetsFacile à utiliserSection 3 – modèles classiques34Cours 2 – Cycle de vie de logicielsModèle en V
Inconvénients :Ne gère pas les activités parallèlesNe gère pas explicitement les changements des spécificationsNe contient pas d’activités d’analyse de risqueSection 3 – modèles classiques35Cours 2 – Cycle de vie de logicielsModèle en V
Quand l’utiliser:Quand le produit à développer à de très hautes exigences de qualitéQuand les besoins sont connus à l’avanceLes technologies à utiliser sont connues à l’avanceSection 3 – modèles classiques36Cours 2 – Cycle de vie de logicielsModèle en V
Le projet se fait sur plusieurs itérationsLes développeurs construisent un prototype selon les attentes du clientLe prototype est évalué par le clientLe client donne son feedbackLes développeurs adaptent le prototype selon les besoins du clientQuand le prototype satisfait le client, le code est normalisé selon les standards et les bonnes pratiquesSection 3 – modèles classiques37Cours 2 – Cycle de vie de logicielsPrototypage
Section 3 – modèles classiques38Cours 2 – Cycle de vie de logicielsPrototypage
AvantagesImplication active du clientLe développeur apprend directement du clientS’adapte rapidement aux changements des besoinsProgrès constant et visibleUne grande interaction avec le produitSection 3 – modèles classiques39Cours 2 – Cycle de vie de logicielsPrototypage
InconvénientsLe prototypage implique un code faiblement structuréDegré très faible de maintenabilitéLe processus peut ne jamais s’arrêterTrès difficile d’établir un planningSection 3 – modèles classiques40Cours 2 – Cycle de vie de logicielsInconvénients
Quand l’utiliser ?Quand les besoins sont instables et/ou nécessitent des clarificationsPeut être utilisé avec le modèle en cascade pour la clarification des besoinsQuand des livraisons rapides sont exigéesSection 3 – modèles classiques41Cours 2 – Cycle de vie de logicielsInconvénients
Chaque incrément est une construction partielle du logicielTrie les spécifications par priorités et les regroupent dans des groupes de spécificationsChaque incrément implémente un ou plusieurs groupes jusqu’à ce que la totalité du produit soit finieSection 3 – modèles classiques42Cours 2 – Cycle de vie de logicielsModèle Incrémental
Section 3 – modèles classiques43Cours 2 – Cycle de vie de logicielsModèle IncrémentalIncrément 1Incrément  2Incrément  NSpécificationsConceptionImplémentationTestsSpécificationsConceptionImplémentationTestsSpécificationsConceptionImplémentationTests
AvantagesDéveloppement de fonctionnalités à risque en premierChaque incrément donne un produit fonctionnelLe client intervient à la fin de chaque incrémentUtiliser l’approche « diviser pour régner »Le client entre en relation avec le produit très tôtSection 3 – modèles classiques44Cours 2 – Cycle de vie de logicielsModèle Incrémental
InconvénientsExige une bonne planification et une bonne conceptionExige une vision sur le produit fini pour pouvoir le diviser en incrémentsLe coût total du système peut être cherSection 3 – modèles classiques45Cours 2 – Cycle de vie de logicielsModèle Incrémental
Quand l’utiliser ?Quand la plupart des spécifications sont connues à l’avances et vont être sujettes à de faibles évolutionsQuand on veut rapidement un produit fonctionnelPour des projets de longues duréesPour des projets impliquant de nouvelles technologiesSection 3 – modèles classiques46Cours 2 – Cycle de vie de logicielsModèle Incrémental
Modèle itératifDes incréments sous forme de cycleÀ la fin de chaque cycle on détermine les objectifs du cycle suivantChaque cycle est composé des même activités que du modèle en cascadeInclut l’analyse de risque et le prototypageSection 3 – modèles classiques47Cours 2 – Cycle de vie de logicielsModèle en spirale
Section 3 – modèles classiques48Cours 2 – Cycle de vie de logicielsModèle en spirale
Détermination des objectifsEn 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.Section 3 – modèles classiques49Cours 2 – Cycle de vie de logicielsModèle en spirale
Identification et évaluation de risquesEtudier les alternatives de développementIdentification 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éSection 3 – modèles classiques50Cours 2 – Cycle de vie de logicielsModèle en spirale
Développement et testContient pratiquement la plupart des activités : conception, codage, test, … etc.Planification de la prochaine itérationUn planning de l’itérationUn plan de testsSection 3 – modèles classiques51Cours 2 – Cycle de vie de logicielsModèle en spirale
AvantagesIdentification rapide des risquesImpacts minimaux des risques sur le projetFonctions critiques développées en premierFeedback rapide du clientUne évaluation continue du procédéSection 3 – modèles classiques52Cours 2 – Cycle de vie de logicielsModèle en spirale
InconvénientsL’évaluation des risques peut prendre beaucoup de tempsLe modèle est très complexeLa spirale peut s’éterniserLes développeurs doivent être réaffectés pendant les phases de non-développementLes objectifs ne sont pas souvent faciles à formulerSection 3 – modèles classiques53Cours 2 – Cycle de vie de logicielsModèle en spirale
Quand est-ce que l’utiliser ?Quand le prototypage est exigéQuand le risque du projet est considérableQuand les spécifications ne sont pas stablesPour les nouveaux produitsQuand le projet implique de la recherche et de l’investigationSection 3 – modèles classiques54Cours 2 – Cycle de vie de logicielsModèle en spirale
Cycles de vie de logiciels55Cours iglSection 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 ?Cycles de vie de logiciels56Cours iglSection 4 : Méthodologies Agiles
Au milieu des années 90, un groupe d’expert en Cycles de vie de logiciels voulaient proposer de nouveaux modèlesLes 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éduiteCes modèles permettent de s’ajuster rapidement aux changements des spécifications tout en garantissant des livraisons fréquentesCes modèles sont qualifiés de « modèles agiles »Section 4 – méthodes agiles57Cours 2 – Cycle de vie de logicielsApparition
Section 4 – méthodes agiles58Cours 2 – Cycle de vie de logicielsPrincipes agiles
INDIVIDUS ET INTERACTIONS AU LIEU DE PROCESSUS ET OUTILSLes collaborateurs sont la clé du succèsLes « seniors » échoueront s’ils ne collaborent pas en tant qu’équipeUn bon collaborateur n’est pas un forcément un bon programmeur. C’est quelqu’un qui travaille bien en équipeUne surabondance d’outils est aussi mauvaise que le manque d’outilsDémarrer petit et investir peu au démarrageConstruire l’équipe c’est plus important que construire l’environnementSection 4 – méthodes agiles59Cours 2 – Cycle de vie de logicielsPrincipes
LOGICIEL FONCTIONNEL AU LIEU DE DOCUMENTATION MASSIVEUn code sans documentation est un désastreTrop de documents est pire que pas de documentsDifficulté à produire et à synchroniser avec le codeSouvent les documents sont des « mensonges » formelsLe code ne ment jamais sur lui-mêmeProduire toujours des documents aussi courts que possibleSection 4 – méthodes agiles60Cours 2 – Cycle de vie de logicielsPrincipes
COLLABORATION DU CLIENT AU LIEU DE LA NÉGOCIATION DE CONTRATSTrès difficile de décrire la totalité du logiciel depuis le débutLes projets réussis impliquent les clients d’une manière fréquente et régulièreLe client doit avoir un contact direct avec l’équipe de développementSection 4 – méthodes agiles61Cours 2 – Cycle de vie de logicielsPrincipes
RÉAGIR AUX CHANGEMENTS AU LIEU DE SUIVRE UN PLANUn logiciel ne peut pas être planifié très loin dans le futurTout change : technologie, environnement et surtout les besoinsLes chefs de projets classiques fonctionnent sur la base de GANTT, PERT et le système de tâchesAvec le temps, les diagrammes se dégradent car des tâches s’ajoutent et d’autres deviennent non nécessairesUne 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àSection 4 – méthodes agiles62Cours 2 – Cycle de vie de logicielsPrincipes
LES DOUZE PRINCIPES AGILESToujours satisfaire le client à travers des livraisons rapides et continuesBien accueillir tous les changements même les tardifsLivrer fréquemment un système fonctionnelLes clients et les développeurs doivent collaborerConduire le projet autour d’équipes motivéesLa meilleure méthode de faire circuler l’information c’est le contact direct entre collaborateursLa première mesure d’avancement c’est un logiciel fonctionnelSection 4 – méthodes agiles63Cours 2 – Cycle de vie de logicielsPrincipes
LES DOUZE PRINCIPES AGILESLe développement doit être durable et à un rythme constantLa bonne conception et l’excellence technique augmentent l’agilitéSimplifier au maximumLes meilleurs architectures, besoins et conceptions proviennent d’équipes qui s’organisent d’elles-mêmesL’équipe s’améliore d’une manière autonome et régulièreSection 4 – méthodes agiles64Cours 2 – Cycle de vie de logicielsPrincipes
Section 4 – méthodes agiles65Cours 2 – Cycle de vie de logicielsPrincipales méthodologies agiles
eXtreme ProgrammingCréée en 1995 Kent Beck and Ward CunninghamXP est un moyen léger, efficace, à bas risques, flexible, scientifique et amusant de développer des logicielsDestinée à des équipes de moyenne taille avec des spécifications incomplets et / ou vaguesLe codage est le noyau de XPSection 4 – méthodes agiles66Cours 2 – Cycle de vie de logicielsMéthodologie XP
Section 4 – méthodes agiles67Cours 2 – Cycle de vie de logicielsMéthodologie XP - Fondamentaux
Section 4 – méthodes agiles68Cours 2 – Cycle de vie de logicielsMéthodologie XP – Principales activités
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 client2 – 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 courtsSection 4 – méthodes agiles69Cours 2 – Cycle de vie de logicielsMéthodologie XP – Les 12 pratiques
3- LES MÉTAPHORESExprimer de manière naturelle et très simples des fonctions du systèmeLe client et les développeurs doivent s’accorder sur les métaphores4 – CONCEPTION SIMPLELe système doit être conçu de la manière la plus simple possible5 – TESTSLes développeurs rédigent les tests unitaires d’une manière continue, Le client rédige les tests d’acceptation des fonctionnalités,Section 4 – méthodes agiles70Cours 2 – Cycle de vie de logicielsMéthodologie XP – Les 12 pratiques
6 – REFACTORINGLes développeurs améliorent continuellement le code tout en veillant à le garder fonctionnel7 – PROGRAMMATION PAR PAIRESLa 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É COLLECTIVEN’importe qui peut changer le code n’importe où dans le système à n’importe quel moment9 - 40 HEURES LA SEMAINELe travail ne doit pas dépasser 40 heures par semaineSection 4 – méthodes agiles71Cours 2 – Cycle de vie de logicielsMéthodologie XP – Les 12 pratiques
10 – intégration continueConstruire le système à chaque fois qu’une tâche est terminée.11 – Le client est sur siteLe client est tout le temps présent avec l’équipe pour participer et répondre aux questions12 – 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éveloppementSection 4 – méthodes agiles72Cours 2 – Cycle de vie de logicielsMéthodologie XP – Les 12 pratiques
Implication active du clientForte réactivité des développeursResponsabilisation et solidarité de l’équipeAppel aux meilleurs pratiques de développementSouplesse extrêmeSection 4 – méthodes agiles73Cours 2 – Cycle de vie de logicielsMéthodologie XP – Avantages
Demande une certaine maturité des développeursLa programmation par paires n’est toujours pas applicableDifficulté de planifier et de budgétiser un projetStress dû aux devoir de l’intégration continue et des livraisons fréquentesLa faible documentation peut nuire en cas de départ des développeursSection 4 – méthodes agiles74Cours 2 – Cycle de vie de logicielsMéthodologie XP – Inconvénients
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 1991Utilisé comme méthodologie dans le livre : « Agile Software Developmentt with SCRUM” par K. Schwaber et M.. Beedlle en 2001Section 4 – méthodes agiles75Cours 2 – Cycle de vie de logicielsMéthodologie Scrum
Section 4 – méthodes agiles76Cours 2 – Cycle de vie de logicielsMéthodologie Scrum - Principes
Section 4 – méthodes agiles77Cours 2 – Cycle de vie de logicielsMéthodologie Scrum - Principes
Section 4 – méthodes agiles78Cours 2 – Cycle de vie de logicielsMéthodologie Scrum - Principes
Méthode très simple et très efficaceAdoptée par les géants du marché : Microsoft, Google, Nokia..Orientée projet contrairement à XP qui est orientée développementPeut inclure d’autres activité venant d’autres méthodologies (surtout XP)Section 4 – méthodes agiles79Cours 2 – Cycle de vie de logicielsMéthodologie Scrum - Avantages
N’est pas 100% spécifique au GLDifficulté de budgétiser un projetSection 4 – méthodes agiles80Cours 2 – Cycle de vie de logicielsMéthodologie Scrum - Inconvénients
Cycles de vie de logiciels81Cours iglSection 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 ?Cycles de vie de logiciels82Cours iglSection 5 : Processus Unifié (Unified Process / UP)
UP est un modèle de procédé très populaireUP est incrémental et itératifUP a plusieurs implémentation et / ou variation dont la plus célèbre est RUP (Rational Unified Process)Section 5 – méthodologie up83Cours 2 – Cycle de vie de logicielsUP
Section 5 – méthodologie up84Cours 2 – Cycle de vie de logicielsUP – Implémentations
Section 5 – méthodologie up85Cours 2 – Cycle de vie de logicielsUP – Principes
PROCESSUS ITÉRATIF ET INCRÉMENTALUP est composé de quatre phase : l’analyse de besoins (inception), l’élaboration, la construction et la transitionChaque phase peut être décomposée en plusieurs itérationsChaque itération produit un incrément du produitSection 5 – méthodologie up86Cours 2 – Cycle de vie de logicielsUP - Principes
PROCESSUS BASÉ SUR LES CAS D’UTILISATIONLes cas d’utilisation formalisent les spécifications fonctionnelle du produitChaque 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éploiementSection 5 – méthodologie up87Cours 2 – Cycle de vie de logicielsUP - Principes
PROCESSUS CENTRÉ SUR L’ARCHITECTUREUP supporte plusieurs architectures logiciellesLa phase d’élaboration fournit l’architecture de l’exécutableCette architecture est une implémentation partielle qui sert de fondation aux développements futursSection 5 – méthodologie up88Cours 2 – Cycle de vie de logicielsUP - Principes
PROCESSUS QUI MET L’ACCENT SUR LES RISQUESIdentification rapide des risquesTraitement des risques dans les premières phases du projetSection 5 – méthodologie up89Cours 2 – Cycle de vie de logicielsUP - Principes
UP est composé de quatre phases principales : analyse de besoins (inception), élaboration, construction et transitionSection 5 – méthodologie up90Cours 2 – Cycle de vie de logicielsUP – Cycle de vie
UP est un processus bidimensionnelLa phase horizontale représente le temps et les étapesLa phase verticale représente les activitésSection 5 – méthodologie up91Cours 2 – Cycle de vie de logicielsUP – Cycle de vie
Section 5 – méthodologie up92Cours 2 – Cycle de vie de logicielsUP – Cycle de vie
PHASE D’ANALYSE DE BESOINS (INCEPTION)La plus petite phase et la plus courteEtablit une vision globale du projetEssaye d’identifier les principaux cas d’utilisationsPropose une ou plusieurs architectures du systèmeIdentifie les risquesEtablit un planning préliminairePeut annuler le projet si l’étape prend trop de tempsSection 5 – méthodologie up93Cours 2 – Cycle de vie de logicielsUP – Cycle de vie
PHASE D’ÉLABORATIONCapturer la majorité des cas d’utilisationValider l’architecture du systèmeEliminer les facteurs de risquePeut décider de ne pas aller au-delàLivrable : prototype exécutable d’architectureLivrable : un planning détaillé et précis sur la phase de constructionSection 5 – méthodologie up94Cours 2 – Cycle de vie de logicielsUP – Cycle de vie
PHASE DE CONSTRUCTIONLa phase la plus longue du projetLe reste du système est développé durant cette phaseChaque itération produit un incrément vers le système finalSection 5 – méthodologie up95Cours 2 – Cycle de vie de logicielsUP – Cycle de vie
PHASE DE TRANSITIONLe système est déployé chez les utilisateursLes feedbacks récoltés serviront à améliorer le systèmeSection 5 – méthodologie up96Cours 2 – Cycle de vie de logicielsUP – Cycle de vie
Expression de besoinsRecenser les besoins fonctionnels et non fonctionnels du systèmeLe diagramme UML de cas d’utilisation est utilisé pour cette phaseSection 5 – méthodologie up97Cours 2 – Cycle de vie de logicielsUP – Activités
AnalyseDétaille les besoins en spécifications détailléesUne ébauche de la conceptionSection 5 – méthodologie up98Cours 2 – Cycle de vie de logicielsUP – Activités
ConceptionDécide comment sera construit le système durant l’implémentationDéfinition des sous-systèmes et composantsCréation d’abstractions de la solutionSection 5 – méthodologie up99Cours 2 – Cycle de vie de logicielsUP – Activités
ImplémentationTraduire les résultats de la conception en un système opérationnelLivrables : code source, exécutables, …etc.Section 5 – méthodologie up100Cours 2 – Cycle de vie de logicielsUP – Activités
TestsVérification et validation des résultats de l’implémentationSection 5 – méthodologie up101Cours 2 – Cycle de vie de logicielsUP – Activités
Méthodologie complèteIdentification rapide des risquesLargement adoptée en entrepriseIntégration avec UMLSéparation concise des phases et des livrablesDes formations / livres / tutoriaux disponiblesSection 5 – méthodologie up102Cours 2 – Cycle de vie de logicielsUP – Avantages
Cycles de vie de logiciels103Cours iglDé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 ?Cycles de vie de logiciels104Cours iglSection 6 : Outils de supports (CASE – Computer-Aided Software Engineering)
CASE est un nom donné aux logiciels 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éveloppementOutils case105Cours 2 – Cycle de vie de logicielsIntroduction
Le développement est essentiellement basé sur l’intelligence humaine, là, les outils CASE ne peuvent pas trop intervenirLe 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.Outils case106Cours 2 – Cycle de vie de logicielsLimite 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’outilOutils case107Cours 2 – Cycle de vie de logicielsClassification des CASE

Contenu connexe

Tendances

Modèle en cascade
Modèle en cascadeModèle en cascade
Modèle en cascade
Ghodhbane Mohamed Amine
 
Soutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logicielSoutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logiciel
Siwar GUEMRI
 
UML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouriUML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouri
Mansouri Khalifa
 
Cours uml
Cours umlCours uml
Cours uml
zimamouche1
 
Chp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de ConceptionChp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de Conception
Lilia Sfaxi
 
Développement d’une application Web et mobile d’un annuaire médical
Développement d’une application Web et mobile d’un annuaire médicalDéveloppement d’une application Web et mobile d’un annuaire médical
Développement d’une application Web et mobile d’un annuaire médical
litayem bechir
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
Rabia AZIZA
 
Méthodologie 2 Track Unified Process
Méthodologie 2 Track Unified ProcessMéthodologie 2 Track Unified Process
Méthodologie 2 Track Unified Process
Zakaria Bouazza
 
Architectures 3-tiers (Web)
Architectures 3-tiers (Web)Architectures 3-tiers (Web)
Architectures 3-tiers (Web)
Heithem Abbes
 
Génie Logiciel : les tests
Génie Logiciel : les testsGénie Logiciel : les tests
Génie Logiciel : les tests
Mohammed Amine Mostefai
 
La spécification des besoins
La spécification des besoinsLa spécification des besoins
La spécification des besoins
Ismahen Traya
 
Méthodes agiles
Méthodes agilesMéthodes agiles
Méthodes agiles
Mohammed Amine Mostefai
 
Introduction aux systèmes répartis
Introduction aux systèmes répartisIntroduction aux systèmes répartis
Introduction aux systèmes répartis
Heithem Abbes
 
Support de cours Spring M.youssfi
Support de cours Spring  M.youssfiSupport de cours Spring  M.youssfi
Support de cours Spring M.youssfi
ENSET, Université Hassan II Casablanca
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
Yahyaoui Mohamed Yosri
 
Presentation pfe gestion parc informatique et help desk
Presentation pfe gestion parc informatique et help deskPresentation pfe gestion parc informatique et help desk
Presentation pfe gestion parc informatique et help desk
Raef Ghribi
 
L Architecture Logicielle En Pratique
L Architecture Logicielle En PratiqueL Architecture Logicielle En Pratique
L Architecture Logicielle En Pratique
François Trudel
 
diagramme de séquence UML
diagramme de séquence UMLdiagramme de séquence UML
diagramme de séquence UML
Amir Souissi
 

Tendances (20)

Modèle en cascade
Modèle en cascadeModèle en cascade
Modèle en cascade
 
Soutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logicielSoutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logiciel
 
UML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouriUML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouri
 
Cours uml
Cours umlCours uml
Cours uml
 
Chp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de ConceptionChp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de Conception
 
Développement d’une application Web et mobile d’un annuaire médical
Développement d’une application Web et mobile d’un annuaire médicalDéveloppement d’une application Web et mobile d’un annuaire médical
Développement d’une application Web et mobile d’un annuaire médical
 
Ttup
TtupTtup
Ttup
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
 
Méthodologie 2 Track Unified Process
Méthodologie 2 Track Unified ProcessMéthodologie 2 Track Unified Process
Méthodologie 2 Track Unified Process
 
Architectures 3-tiers (Web)
Architectures 3-tiers (Web)Architectures 3-tiers (Web)
Architectures 3-tiers (Web)
 
Génie Logiciel : les tests
Génie Logiciel : les testsGénie Logiciel : les tests
Génie Logiciel : les tests
 
La spécification des besoins
La spécification des besoinsLa spécification des besoins
La spécification des besoins
 
Méthodes agiles
Méthodes agilesMéthodes agiles
Méthodes agiles
 
Introduction aux systèmes répartis
Introduction aux systèmes répartisIntroduction aux systèmes répartis
Introduction aux systèmes répartis
 
Support de cours Spring M.youssfi
Support de cours Spring  M.youssfiSupport de cours Spring  M.youssfi
Support de cours Spring M.youssfi
 
Génie Logiciel - Cours 5 - analyse
Génie Logiciel - Cours 5 - analyseGénie Logiciel - Cours 5 - analyse
Génie Logiciel - Cours 5 - analyse
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
 
Presentation pfe gestion parc informatique et help desk
Presentation pfe gestion parc informatique et help deskPresentation pfe gestion parc informatique et help desk
Presentation pfe gestion parc informatique et help desk
 
L Architecture Logicielle En Pratique
L Architecture Logicielle En PratiqueL Architecture Logicielle En Pratique
L Architecture Logicielle En Pratique
 
diagramme de séquence UML
diagramme de séquence UMLdiagramme de séquence UML
diagramme de séquence UML
 

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

Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
LatifaBen6
 
Initiation à UML: Partie 1
Initiation à UML: Partie 1Initiation à UML: Partie 1
Initiation à UML: Partie 1
DIALLO Boubacar
 
001GESTION DE PROJET INFO-Cours-GPI.pptx
001GESTION DE PROJET INFO-Cours-GPI.pptx001GESTION DE PROJET INFO-Cours-GPI.pptx
001GESTION DE PROJET INFO-Cours-GPI.pptx
blackmambaettijean
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
testuser715939
 
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptxProcessus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
informatiquehageryah
 
3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciel3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciel
lauraty3204
 
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
jkebbab
 
1bis_ProcessusUnifie.pdf
1bis_ProcessusUnifie.pdf1bis_ProcessusUnifie.pdf
1bis_ProcessusUnifie.pdf
WafaNeji1
 
Atelier Genie Logiciel Developement.pptx
Atelier Genie Logiciel  Developement.pptxAtelier Genie Logiciel  Developement.pptx
Atelier Genie Logiciel Developement.pptx
ssusercb2b311
 
Introduction au Génie Logiciel
Introduction au Génie LogicielIntroduction au Génie Logiciel
Introduction au Génie Logiciel
guest0032c8
 
Cycle de vie des logiciels.ppt
Cycle de vie des logiciels.pptCycle de vie des logiciels.ppt
Cycle de vie des logiciels.ppt
hbadir
 
[Important] Cycle de vie des logiciels.ppt
[Important] Cycle de vie des logiciels.ppt[Important] Cycle de vie des logiciels.ppt
[Important] Cycle de vie des logiciels.ppt
testuser715939
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
Erradi Mohamed
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
Sid Ahmed Benkraoua
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
ssuserec8501
 

Similaire à Cours Génie Logiciel - Cours 2 - Cycles de vie (20)

Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
 
Initiation à UML: Partie 1
Initiation à UML: Partie 1Initiation à UML: Partie 1
Initiation à UML: Partie 1
 
001GESTION DE PROJET INFO-Cours-GPI.pptx
001GESTION DE PROJET INFO-Cours-GPI.pptx001GESTION DE PROJET INFO-Cours-GPI.pptx
001GESTION DE PROJET INFO-Cours-GPI.pptx
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
 
Fichier récupéré 1
Fichier récupéré 1Fichier récupéré 1
Fichier récupéré 1
 
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptxProcessus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
 
CM processus-unifie
CM processus-unifieCM processus-unifie
CM processus-unifie
 
3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciel3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciel
 
CM Processus Méthodes
CM Processus MéthodesCM Processus Méthodes
CM Processus Méthodes
 
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
 
1bis_ProcessusUnifie.pdf
1bis_ProcessusUnifie.pdf1bis_ProcessusUnifie.pdf
1bis_ProcessusUnifie.pdf
 
Atelier Genie Logiciel Developement.pptx
Atelier Genie Logiciel  Developement.pptxAtelier Genie Logiciel  Developement.pptx
Atelier Genie Logiciel Developement.pptx
 
Introduction au Génie Logiciel
Introduction au Génie LogicielIntroduction au Génie Logiciel
Introduction au Génie Logiciel
 
Cycle de vie des logiciels.ppt
Cycle de vie des logiciels.pptCycle de vie des logiciels.ppt
Cycle de vie des logiciels.ppt
 
[Important] Cycle de vie des logiciels.ppt
[Important] Cycle de vie des logiciels.ppt[Important] Cycle de vie des logiciels.ppt
[Important] Cycle de vie des logiciels.ppt
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
UML4
UML4UML4
UML4
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
 
Lecon 1.1
Lecon 1.1Lecon 1.1
Lecon 1.1
 

Plus de Mohammed Amine Mostefai

Utilisation de Sharepoint (Collaboration)
Utilisation de Sharepoint (Collaboration)Utilisation de Sharepoint (Collaboration)
Utilisation de Sharepoint (Collaboration)
Mohammed Amine Mostefai
 
Utilisation de Sharepoint 2013 - Personnalisation
Utilisation de Sharepoint 2013 - PersonnalisationUtilisation de Sharepoint 2013 - Personnalisation
Utilisation de Sharepoint 2013 - Personnalisation
Mohammed Amine Mostefai
 
Utilisation Sharepoint (Listes)
Utilisation Sharepoint (Listes)Utilisation Sharepoint (Listes)
Utilisation Sharepoint (Listes)
Mohammed Amine Mostefai
 
Utilisation de Sharepoint - Gestion de Documents
Utilisation de Sharepoint - Gestion de DocumentsUtilisation de Sharepoint - Gestion de Documents
Utilisation de Sharepoint - Gestion de Documents
Mohammed Amine Mostefai
 
Utilisation de Sharepoiunt - Introduction
Utilisation de Sharepoiunt - IntroductionUtilisation de Sharepoiunt - Introduction
Utilisation de Sharepoiunt - Introduction
Mohammed Amine Mostefai
 
Pratiques agiles
Pratiques agilesPratiques agiles
Pratiques agiles
Mohammed Amine Mostefai
 
Introduction à Scrum
Introduction à ScrumIntroduction à Scrum
Introduction à Scrum
Mohammed Amine Mostefai
 
Méthodes Agiles - La Méthode XP
Méthodes Agiles - La Méthode XPMéthodes Agiles - La Méthode XP
Méthodes Agiles - La Méthode XP
Mohammed Amine Mostefai
 
Le Manifeste Agile
Le Manifeste AgileLe Manifeste Agile
Le Manifeste Agile
Mohammed Amine Mostefai
 
Méthodes Agiles - Généralités
Méthodes Agiles - GénéralitésMéthodes Agiles - Généralités
Méthodes Agiles - Généralités
Mohammed Amine Mostefai
 
Introduction aux technologies mobiles
Introduction aux technologies mobilesIntroduction aux technologies mobiles
Introduction aux technologies mobiles
Mohammed Amine Mostefai
 
Workflow Foundation - Cours 5
Workflow Foundation - Cours 5Workflow Foundation - Cours 5
Workflow Foundation - Cours 5
Mohammed Amine Mostefai
 
Workflow Foundation Module 4
Workflow Foundation Module 4Workflow Foundation Module 4
Workflow Foundation Module 4
Mohammed Amine Mostefai
 
Présentation cloud journée azure
Présentation cloud   journée azurePrésentation cloud   journée azure
Présentation cloud journée azure
Mohammed Amine Mostefai
 
Wf module3
Wf module3Wf module3
Microsoft Workflow Foundation - Cours 2
Microsoft Workflow Foundation - Cours 2Microsoft Workflow Foundation - Cours 2
Microsoft Workflow Foundation - Cours 2
Mohammed Amine Mostefai
 
Introduction to Workflow Foundation
Introduction to Workflow FoundationIntroduction to Workflow Foundation
Introduction to Workflow Foundation
Mohammed Amine Mostefai
 
Le Langage CSS
Le Langage CSSLe Langage CSS
Le Langage CSS
Mohammed Amine Mostefai
 
Sécurisation des applications ASP.NET
Sécurisation des applications ASP.NETSécurisation des applications ASP.NET
Sécurisation des applications ASP.NET
Mohammed Amine Mostefai
 
Présentation sharepoint 2013
Présentation sharepoint 2013Présentation sharepoint 2013
Présentation sharepoint 2013
Mohammed Amine Mostefai
 

Plus de Mohammed Amine Mostefai (20)

Utilisation de Sharepoint (Collaboration)
Utilisation de Sharepoint (Collaboration)Utilisation de Sharepoint (Collaboration)
Utilisation de Sharepoint (Collaboration)
 
Utilisation de Sharepoint 2013 - Personnalisation
Utilisation de Sharepoint 2013 - PersonnalisationUtilisation de Sharepoint 2013 - Personnalisation
Utilisation de Sharepoint 2013 - Personnalisation
 
Utilisation Sharepoint (Listes)
Utilisation Sharepoint (Listes)Utilisation Sharepoint (Listes)
Utilisation Sharepoint (Listes)
 
Utilisation de Sharepoint - Gestion de Documents
Utilisation de Sharepoint - Gestion de DocumentsUtilisation de Sharepoint - Gestion de Documents
Utilisation de Sharepoint - Gestion de Documents
 
Utilisation de Sharepoiunt - Introduction
Utilisation de Sharepoiunt - IntroductionUtilisation de Sharepoiunt - Introduction
Utilisation de Sharepoiunt - Introduction
 
Pratiques agiles
Pratiques agilesPratiques agiles
Pratiques agiles
 
Introduction à Scrum
Introduction à ScrumIntroduction à Scrum
Introduction à Scrum
 
Méthodes Agiles - La Méthode XP
Méthodes Agiles - La Méthode XPMéthodes Agiles - La Méthode XP
Méthodes Agiles - La Méthode XP
 
Le Manifeste Agile
Le Manifeste AgileLe Manifeste Agile
Le Manifeste Agile
 
Méthodes Agiles - Généralités
Méthodes Agiles - GénéralitésMéthodes Agiles - Généralités
Méthodes Agiles - Généralités
 
Introduction aux technologies mobiles
Introduction aux technologies mobilesIntroduction aux technologies mobiles
Introduction aux technologies mobiles
 
Workflow Foundation - Cours 5
Workflow Foundation - Cours 5Workflow Foundation - Cours 5
Workflow Foundation - Cours 5
 
Workflow Foundation Module 4
Workflow Foundation Module 4Workflow Foundation Module 4
Workflow Foundation Module 4
 
Présentation cloud journée azure
Présentation cloud   journée azurePrésentation cloud   journée azure
Présentation cloud journée azure
 
Wf module3
Wf module3Wf module3
Wf module3
 
Microsoft Workflow Foundation - Cours 2
Microsoft Workflow Foundation - Cours 2Microsoft Workflow Foundation - Cours 2
Microsoft Workflow Foundation - Cours 2
 
Introduction to Workflow Foundation
Introduction to Workflow FoundationIntroduction to Workflow Foundation
Introduction to Workflow Foundation
 
Le Langage CSS
Le Langage CSSLe Langage CSS
Le Langage CSS
 
Sécurisation des applications ASP.NET
Sécurisation des applications ASP.NETSécurisation des applications ASP.NET
Sécurisation des applications ASP.NET
 
Présentation sharepoint 2013
Présentation sharepoint 2013Présentation sharepoint 2013
Présentation sharepoint 2013
 

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

  • 1. Cours 2 :Cycles de vie de logicielsCours IGLcours 2Cycles de vie de logiciels1Mostefai Mohammed Amine – m_mostefai@esi.dzBatata Sofiane – s_batata@esi.dz
  • 2. Découvrir les principales activités de développement de logicielsConnaître les cycles de vie (SDLC) et leur motivationConnaître les SDLC classiques et les méthodes agilesPourvoir choisir un SDLC sur la base des données concernant un projet de développementPrise de contact avec la méthodologie UPDécouvrir les outils de support (CASE)Objectifs du cours2Cours 2 – Cycle de vie de logicielsObjectifs du cours
  • 3. Cours 2Cycles de vie de logiciels3Introduction au génie logiciel
  • 4. Cycles de vie de logiciels4Cours iglSection 1 : Activités de développement
  • 5. Tout logiciel passe par plusieurs étapes pour être développéCes étapes peuvent être résumées dans les étapes ci-dessous :Section 1 - introduction5Cours 2 – Cycle de vie de logicielsEtapes de développement
  • 6. Définir les besoins :Que doit faire le logicielDe quelle façonEt sous quelles conditionsSection 1 - introduction6Cours 2 – Cycle de vie de logicielsDéfinition
  • 7. Transformation des données collectées pendant l’étape de définition en plusieurs produits :Logiciel fonctionnelCode sourceProduits connexesSection 1 - introduction7Cours 2 – Cycle de vie de logicielsDéveloppement
  • 8. Section 1 - introduction8Cours 2 – Cycle de vie de logicielsSupport
  • 9. 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 maintenanceSection 1 - introduction9Cours 2 – Cycle de vie de logicielsSupport
  • 10. Chaque projet de développement est composé de plusieurs activitésChaque activité est conduite et réalisée par plusieurs acteursUne 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épendentPar exemple : document, planning, code source sont tous des livrablesSection 1 - introduction10Cours 2 – Cycle de vie de logicielsActivités
  • 11. Tous les projets de développement ont des activités communesSection 1 - introduction11Cours 2 – Cycle de vie de logicielsPrincipales activités
  • 12. Conditions qui doivent être respectées par un nouveau produit ou un produit altéréAussi appelé spécificationsDans les grands projets (par exemple projets nationaux), c’est composé d’un cahier de chargesCette phase est difficile car le client et les développeurs ne parlent pas le même langageLe livrable de cette phase est un document de spécificationSection 1 - introduction12Cours 2 – Cycle de vie de logicielsAnalyse de besoins
  • 13. La conception utilise les spécifications pour décider les solutions relatives au différents problèmes de développementLa conception décide aussi d’un planning de la solutionLa conception décide de l’architecture de la solutionSi le produit est centré sur l’utilisateur, la conception propose une ébauche de l’interface utilisateurSection 1 - introduction13Cours 2 – Cycle de vie de logicielsConception
  • 14. Le codage est une activité très importante du GLLe codage transforme les solutions proposées lors de la conception en un code opérationnelLa 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. Section 1 - introduction14Cours 2 – Cycle de vie de logicielsCodage
  • 15. Les tests déterminent la qualité du logicielLes tests déterminent si le logiciel fait ce qu’on attend de lui par rapport aux spécificationsPlusieurs types de test dont deux principaux : tests unitaires et tests d’acceptationLes tests unitaires sont orientés code. Ils se rédigent durant l’activité de codage et se revérifient pendant la phase de testLes tests d’acceptation vérifient les attentes d’un produit logicielSection 1 - introduction15Cours 2 – Cycle de vie de logicielsTests
  • 16. La maintenance consiste à modifier le produit (le logiciel) après sa livraison au clientSon but est correctif ou évolutifLa maintenance a deux facettes : organisationnelle et techniqueL’aspect organisationnel concerne l’organisation des équipes pour une réactivité face aux changementsL’aspect technique concerne une maintenance sans impact négatif sur le produitLe degré de maintenance dépend de la qualité de la conceptionSection 1 - introduction16Cours 2 – Cycle de vie de logicielsMaintenance
  • 17. Cycles de vie de logiciels17COURS IGLDébat (10 Mns)
  • 18. Cycles de vie de logiciels18Cours iglSection 2 : Cycle de vie de logiciels
  • 19. Un procédé logiciel (software process) est un ensemble d’activités conduisant à la production d’un logicielIls 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înementLes Cycles de vie de logiciels sont complexes et dépendent fortement des acteurs qui dirigent les activitésLes 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)Section 2 – Cycles de vie de logiciels19Cours 2 – Cycle de vie de logicielsProcédé Logiciel
  • 20. Un modèle de procédé est une abstraction d’un procédéUn modèle décrit le procédé selon une certaine perspectiveUn procédé logiciel est une application d’un modèle pour un projet spécifique, qui peut inclure une certaine adaptationSection 2 – Cycles de vie de logiciels20Cours 2 – Cycle de vie de logicielsModèles de procédés
  • 21. Pour maîtriser les gros projetsPour découper le projet et affecter correctement les tâchesPour anticiper et gérer les risquesSection 2 – Cycles de vie de logiciels21Cours 2 – Cycle de vie de logicielsModèles de procédés – Pourquoi ?
  • 22. Il existe deux types de modèles de procédés :Section 2 – Cycles de vie de logiciels22Cours 2 – Cycle de vie de logicielsModèles de procédés
  • 23. Section 2 – Cycles de vie de logiciels23Cours 2 – Cycle de vie de logicielsModèles de procédés
  • 24. Aucun modèle n’est meilleur que l’autreLe 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’équipeSection 2 – Cycles de vie de logiciels24Cours 2 – Cycle de vie de logicielsChoix d’un modèle
  • 25. Cycles de Vie des Logiciels25Cours iglSection 2 : Débat (5 mn)Qu’est-ce qu’un gros projet ?
  • 26. Comment mesure-t-on un gros projet ?
  • 27. Pourquoi un modèle de procédé est-il essentiel pour conduire un projet de développement ?Cycles de vie de logiciels26Cours iglSection 3 : Cycles de vie classiques
  • 28. L’un des premiers modèles proposés, inspiré du modèle de Royce (1970)Aussi appelé modèle linéaireLe résultat de chaque phase est un ensemble de livrables,Une phase ne peut démarrer que si la précédente est finieLe modèle académique par excellenceSection 3 – modèles classiques27Cours 2 – Cycle de vie de logicielsModèle en cascade
  • 29. Section 3 – modèles classiques28Cours 2 – Cycle de vie de logicielsModèle en cascade
  • 30. Avantages :Facile à utiliser et à comprendreUn procédé structuré pour une équipe inexpérimentéeIdéal pour la gestion et le suivi de projetsFonctionne très bien quand la qualité est plus importante que les coûts et les délaisSection 3 – modèles classiques29Cours 2 – Cycle de vie de logicielsModèle en cascade
  • 31. Inconvénients :Les besoins des clients sont très rarement stables et clairement définisSensibilité aux nouveaux besoins : refaire tout le procédéUne phase ne peut démarrer que si l’étape précédente est finieLe produit n’est visible qu’à la finLes risques se décalent vers la finTrès faible implication du clientSection 3 – modèles classiques30Cours 2 – Cycle de vie de logicielsModèle en cascade
  • 32. Quand l’utiliser ?Quand les besoins sont connus et stablesQuand la technologie à utiliser est maîtriséeLors de la création d’une nouvelle version d’un produit existantLors du portage d’un produit sur une autre plateformeSection 3 – modèles classiques31Cours 2 – Cycle de vie de logicielsModèle en cascade
  • 33. Variante du modèle en cascade qui fait l’accent sur la vérification et la validationLe test du produit se fait en parallèle par rapport aux autres activitésSection 3 – modèles classiques32Cours 2 – Cycle de vie de logicielsModèle en V
  • 34. Section 3 – modèles classiques33Cours 2 – Cycle de vie de logicielsModèle en V
  • 35. Avantages :Met l’accent sur lest tests et la validation et par conséquent, ça accroît la qualité du logicielChaque livrable doit être testableFacile à planifier dans une gestion de projetsFacile à utiliserSection 3 – modèles classiques34Cours 2 – Cycle de vie de logicielsModèle en V
  • 36. Inconvénients :Ne gère pas les activités parallèlesNe gère pas explicitement les changements des spécificationsNe contient pas d’activités d’analyse de risqueSection 3 – modèles classiques35Cours 2 – Cycle de vie de logicielsModèle en V
  • 37. Quand l’utiliser:Quand le produit à développer à de très hautes exigences de qualitéQuand les besoins sont connus à l’avanceLes technologies à utiliser sont connues à l’avanceSection 3 – modèles classiques36Cours 2 – Cycle de vie de logicielsModèle en V
  • 38. Le projet se fait sur plusieurs itérationsLes développeurs construisent un prototype selon les attentes du clientLe prototype est évalué par le clientLe client donne son feedbackLes développeurs adaptent le prototype selon les besoins du clientQuand le prototype satisfait le client, le code est normalisé selon les standards et les bonnes pratiquesSection 3 – modèles classiques37Cours 2 – Cycle de vie de logicielsPrototypage
  • 39. Section 3 – modèles classiques38Cours 2 – Cycle de vie de logicielsPrototypage
  • 40. AvantagesImplication active du clientLe développeur apprend directement du clientS’adapte rapidement aux changements des besoinsProgrès constant et visibleUne grande interaction avec le produitSection 3 – modèles classiques39Cours 2 – Cycle de vie de logicielsPrototypage
  • 41. InconvénientsLe prototypage implique un code faiblement structuréDegré très faible de maintenabilitéLe processus peut ne jamais s’arrêterTrès difficile d’établir un planningSection 3 – modèles classiques40Cours 2 – Cycle de vie de logicielsInconvénients
  • 42. Quand l’utiliser ?Quand les besoins sont instables et/ou nécessitent des clarificationsPeut être utilisé avec le modèle en cascade pour la clarification des besoinsQuand des livraisons rapides sont exigéesSection 3 – modèles classiques41Cours 2 – Cycle de vie de logicielsInconvénients
  • 43. Chaque incrément est une construction partielle du logicielTrie les spécifications par priorités et les regroupent dans des groupes de spécificationsChaque incrément implémente un ou plusieurs groupes jusqu’à ce que la totalité du produit soit finieSection 3 – modèles classiques42Cours 2 – Cycle de vie de logicielsModèle Incrémental
  • 44. Section 3 – modèles classiques43Cours 2 – Cycle de vie de logicielsModèle IncrémentalIncrément 1Incrément 2Incrément NSpécificationsConceptionImplémentationTestsSpécificationsConceptionImplémentationTestsSpécificationsConceptionImplémentationTests
  • 45. AvantagesDéveloppement de fonctionnalités à risque en premierChaque incrément donne un produit fonctionnelLe client intervient à la fin de chaque incrémentUtiliser l’approche « diviser pour régner »Le client entre en relation avec le produit très tôtSection 3 – modèles classiques44Cours 2 – Cycle de vie de logicielsModèle Incrémental
  • 46. InconvénientsExige une bonne planification et une bonne conceptionExige une vision sur le produit fini pour pouvoir le diviser en incrémentsLe coût total du système peut être cherSection 3 – modèles classiques45Cours 2 – Cycle de vie de logicielsModèle Incrémental
  • 47. Quand l’utiliser ?Quand la plupart des spécifications sont connues à l’avances et vont être sujettes à de faibles évolutionsQuand on veut rapidement un produit fonctionnelPour des projets de longues duréesPour des projets impliquant de nouvelles technologiesSection 3 – modèles classiques46Cours 2 – Cycle de vie de logicielsModèle Incrémental
  • 48. Modèle itératifDes incréments sous forme de cycleÀ la fin de chaque cycle on détermine les objectifs du cycle suivantChaque cycle est composé des même activités que du modèle en cascadeInclut l’analyse de risque et le prototypageSection 3 – modèles classiques47Cours 2 – Cycle de vie de logicielsModèle en spirale
  • 49. Section 3 – modèles classiques48Cours 2 – Cycle de vie de logicielsModèle en spirale
  • 50. Détermination des objectifsEn 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.Section 3 – modèles classiques49Cours 2 – Cycle de vie de logicielsModèle en spirale
  • 51. Identification et évaluation de risquesEtudier les alternatives de développementIdentification 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éSection 3 – modèles classiques50Cours 2 – Cycle de vie de logicielsModèle en spirale
  • 52. Développement et testContient pratiquement la plupart des activités : conception, codage, test, … etc.Planification de la prochaine itérationUn planning de l’itérationUn plan de testsSection 3 – modèles classiques51Cours 2 – Cycle de vie de logicielsModèle en spirale
  • 53. AvantagesIdentification rapide des risquesImpacts minimaux des risques sur le projetFonctions critiques développées en premierFeedback rapide du clientUne évaluation continue du procédéSection 3 – modèles classiques52Cours 2 – Cycle de vie de logicielsModèle en spirale
  • 54. InconvénientsL’évaluation des risques peut prendre beaucoup de tempsLe modèle est très complexeLa spirale peut s’éterniserLes développeurs doivent être réaffectés pendant les phases de non-développementLes objectifs ne sont pas souvent faciles à formulerSection 3 – modèles classiques53Cours 2 – Cycle de vie de logicielsModèle en spirale
  • 55. Quand est-ce que l’utiliser ?Quand le prototypage est exigéQuand le risque du projet est considérableQuand les spécifications ne sont pas stablesPour les nouveaux produitsQuand le projet implique de la recherche et de l’investigationSection 3 – modèles classiques54Cours 2 – Cycle de vie de logicielsModèle en spirale
  • 56. Cycles de vie de logiciels55Cours iglSection 3 : Débat (15 Mn)Quel est le modèle le plus simple et le plus complexe ?
  • 57. Quels sont les critères qui définiront quel modèle choisir ?
  • 58. Quelle est la chose la plus difficile pour un modèle incrémental ou itératif ?Cycles de vie de logiciels56Cours iglSection 4 : Méthodologies Agiles
  • 59. Au milieu des années 90, un groupe d’expert en Cycles de vie de logiciels voulaient proposer de nouveaux modèlesLes 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éduiteCes modèles permettent de s’ajuster rapidement aux changements des spécifications tout en garantissant des livraisons fréquentesCes modèles sont qualifiés de « modèles agiles »Section 4 – méthodes agiles57Cours 2 – Cycle de vie de logicielsApparition
  • 60. Section 4 – méthodes agiles58Cours 2 – Cycle de vie de logicielsPrincipes agiles
  • 61. INDIVIDUS ET INTERACTIONS AU LIEU DE PROCESSUS ET OUTILSLes collaborateurs sont la clé du succèsLes « seniors » échoueront s’ils ne collaborent pas en tant qu’équipeUn bon collaborateur n’est pas un forcément un bon programmeur. C’est quelqu’un qui travaille bien en équipeUne surabondance d’outils est aussi mauvaise que le manque d’outilsDémarrer petit et investir peu au démarrageConstruire l’équipe c’est plus important que construire l’environnementSection 4 – méthodes agiles59Cours 2 – Cycle de vie de logicielsPrincipes
  • 62. LOGICIEL FONCTIONNEL AU LIEU DE DOCUMENTATION MASSIVEUn code sans documentation est un désastreTrop de documents est pire que pas de documentsDifficulté à produire et à synchroniser avec le codeSouvent les documents sont des « mensonges » formelsLe code ne ment jamais sur lui-mêmeProduire toujours des documents aussi courts que possibleSection 4 – méthodes agiles60Cours 2 – Cycle de vie de logicielsPrincipes
  • 63. COLLABORATION DU CLIENT AU LIEU DE LA NÉGOCIATION DE CONTRATSTrès difficile de décrire la totalité du logiciel depuis le débutLes projets réussis impliquent les clients d’une manière fréquente et régulièreLe client doit avoir un contact direct avec l’équipe de développementSection 4 – méthodes agiles61Cours 2 – Cycle de vie de logicielsPrincipes
  • 64. RÉAGIR AUX CHANGEMENTS AU LIEU DE SUIVRE UN PLANUn logiciel ne peut pas être planifié très loin dans le futurTout change : technologie, environnement et surtout les besoinsLes chefs de projets classiques fonctionnent sur la base de GANTT, PERT et le système de tâchesAvec le temps, les diagrammes se dégradent car des tâches s’ajoutent et d’autres deviennent non nécessairesUne 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àSection 4 – méthodes agiles62Cours 2 – Cycle de vie de logicielsPrincipes
  • 65. LES DOUZE PRINCIPES AGILESToujours satisfaire le client à travers des livraisons rapides et continuesBien accueillir tous les changements même les tardifsLivrer fréquemment un système fonctionnelLes clients et les développeurs doivent collaborerConduire le projet autour d’équipes motivéesLa meilleure méthode de faire circuler l’information c’est le contact direct entre collaborateursLa première mesure d’avancement c’est un logiciel fonctionnelSection 4 – méthodes agiles63Cours 2 – Cycle de vie de logicielsPrincipes
  • 66. LES DOUZE PRINCIPES AGILESLe développement doit être durable et à un rythme constantLa bonne conception et l’excellence technique augmentent l’agilitéSimplifier au maximumLes meilleurs architectures, besoins et conceptions proviennent d’équipes qui s’organisent d’elles-mêmesL’équipe s’améliore d’une manière autonome et régulièreSection 4 – méthodes agiles64Cours 2 – Cycle de vie de logicielsPrincipes
  • 67. Section 4 – méthodes agiles65Cours 2 – Cycle de vie de logicielsPrincipales méthodologies agiles
  • 68. eXtreme ProgrammingCréée en 1995 Kent Beck and Ward CunninghamXP est un moyen léger, efficace, à bas risques, flexible, scientifique et amusant de développer des logicielsDestinée à des équipes de moyenne taille avec des spécifications incomplets et / ou vaguesLe codage est le noyau de XPSection 4 – méthodes agiles66Cours 2 – Cycle de vie de logicielsMéthodologie XP
  • 69. Section 4 – méthodes agiles67Cours 2 – Cycle de vie de logicielsMéthodologie XP - Fondamentaux
  • 70. Section 4 – méthodes agiles68Cours 2 – Cycle de vie de logicielsMéthodologie XP – Principales activités
  • 71. 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 client2 – 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 courtsSection 4 – méthodes agiles69Cours 2 – Cycle de vie de logicielsMéthodologie XP – Les 12 pratiques
  • 72. 3- LES MÉTAPHORESExprimer de manière naturelle et très simples des fonctions du systèmeLe client et les développeurs doivent s’accorder sur les métaphores4 – CONCEPTION SIMPLELe système doit être conçu de la manière la plus simple possible5 – TESTSLes développeurs rédigent les tests unitaires d’une manière continue, Le client rédige les tests d’acceptation des fonctionnalités,Section 4 – méthodes agiles70Cours 2 – Cycle de vie de logicielsMéthodologie XP – Les 12 pratiques
  • 73. 6 – REFACTORINGLes développeurs améliorent continuellement le code tout en veillant à le garder fonctionnel7 – PROGRAMMATION PAR PAIRESLa 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É COLLECTIVEN’importe qui peut changer le code n’importe où dans le système à n’importe quel moment9 - 40 HEURES LA SEMAINELe travail ne doit pas dépasser 40 heures par semaineSection 4 – méthodes agiles71Cours 2 – Cycle de vie de logicielsMéthodologie XP – Les 12 pratiques
  • 74. 10 – intégration continueConstruire le système à chaque fois qu’une tâche est terminée.11 – Le client est sur siteLe client est tout le temps présent avec l’équipe pour participer et répondre aux questions12 – 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éveloppementSection 4 – méthodes agiles72Cours 2 – Cycle de vie de logicielsMéthodologie XP – Les 12 pratiques
  • 75. Implication active du clientForte réactivité des développeursResponsabilisation et solidarité de l’équipeAppel aux meilleurs pratiques de développementSouplesse extrêmeSection 4 – méthodes agiles73Cours 2 – Cycle de vie de logicielsMéthodologie XP – Avantages
  • 76. Demande une certaine maturité des développeursLa programmation par paires n’est toujours pas applicableDifficulté de planifier et de budgétiser un projetStress dû aux devoir de l’intégration continue et des livraisons fréquentesLa faible documentation peut nuire en cas de départ des développeursSection 4 – méthodes agiles74Cours 2 – Cycle de vie de logicielsMéthodologie XP – Inconvénients
  • 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 1991Utilisé comme méthodologie dans le livre : « Agile Software Developmentt with SCRUM” par K. Schwaber et M.. Beedlle en 2001Section 4 – méthodes agiles75Cours 2 – Cycle de vie de logicielsMéthodologie Scrum
  • 78. Section 4 – méthodes agiles76Cours 2 – Cycle de vie de logicielsMéthodologie Scrum - Principes
  • 79. Section 4 – méthodes agiles77Cours 2 – Cycle de vie de logicielsMéthodologie Scrum - Principes
  • 80. Section 4 – méthodes agiles78Cours 2 – Cycle de vie de logicielsMéthodologie Scrum - Principes
  • 81. Méthode très simple et très efficaceAdoptée par les géants du marché : Microsoft, Google, Nokia..Orientée projet contrairement à XP qui est orientée développementPeut inclure d’autres activité venant d’autres méthodologies (surtout XP)Section 4 – méthodes agiles79Cours 2 – Cycle de vie de logicielsMéthodologie Scrum - Avantages
  • 82. N’est pas 100% spécifique au GLDifficulté de budgétiser un projetSection 4 – méthodes agiles80Cours 2 – Cycle de vie de logicielsMéthodologie Scrum - Inconvénients
  • 83. Cycles de vie de logiciels81Cours iglSection 4 : Débat (10 mns)Quelles sont les différences entre une méthode agile et une méthode classique ?
  • 84. Quels sont les points forts des méthodes agiles ?
  • 85. Quels en sont les points faibles ?
  • 86. Quelle est la différence entre Scrum et XP ?
  • 87. Est-ce que Scrum et XP peuvent-elles être combinées ?Cycles de vie de logiciels82Cours iglSection 5 : Processus Unifié (Unified Process / UP)
  • 88. UP est un modèle de procédé très populaireUP est incrémental et itératifUP a plusieurs implémentation et / ou variation dont la plus célèbre est RUP (Rational Unified Process)Section 5 – méthodologie up83Cours 2 – Cycle de vie de logicielsUP
  • 89. Section 5 – méthodologie up84Cours 2 – Cycle de vie de logicielsUP – Implémentations
  • 90. Section 5 – méthodologie up85Cours 2 – Cycle de vie de logicielsUP – Principes
  • 91. PROCESSUS ITÉRATIF ET INCRÉMENTALUP est composé de quatre phase : l’analyse de besoins (inception), l’élaboration, la construction et la transitionChaque phase peut être décomposée en plusieurs itérationsChaque itération produit un incrément du produitSection 5 – méthodologie up86Cours 2 – Cycle de vie de logicielsUP - Principes
  • 92. PROCESSUS BASÉ SUR LES CAS D’UTILISATIONLes cas d’utilisation formalisent les spécifications fonctionnelle du produitChaque 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éploiementSection 5 – méthodologie up87Cours 2 – Cycle de vie de logicielsUP - Principes
  • 93. PROCESSUS CENTRÉ SUR L’ARCHITECTUREUP supporte plusieurs architectures logiciellesLa phase d’élaboration fournit l’architecture de l’exécutableCette architecture est une implémentation partielle qui sert de fondation aux développements futursSection 5 – méthodologie up88Cours 2 – Cycle de vie de logicielsUP - Principes
  • 94. PROCESSUS QUI MET L’ACCENT SUR LES RISQUESIdentification rapide des risquesTraitement des risques dans les premières phases du projetSection 5 – méthodologie up89Cours 2 – Cycle de vie de logicielsUP - Principes
  • 95. UP est composé de quatre phases principales : analyse de besoins (inception), élaboration, construction et transitionSection 5 – méthodologie up90Cours 2 – Cycle de vie de logicielsUP – Cycle de vie
  • 96. UP est un processus bidimensionnelLa phase horizontale représente le temps et les étapesLa phase verticale représente les activitésSection 5 – méthodologie up91Cours 2 – Cycle de vie de logicielsUP – Cycle de vie
  • 97. Section 5 – méthodologie up92Cours 2 – Cycle de vie de logicielsUP – Cycle de vie
  • 98. PHASE D’ANALYSE DE BESOINS (INCEPTION)La plus petite phase et la plus courteEtablit une vision globale du projetEssaye d’identifier les principaux cas d’utilisationsPropose une ou plusieurs architectures du systèmeIdentifie les risquesEtablit un planning préliminairePeut annuler le projet si l’étape prend trop de tempsSection 5 – méthodologie up93Cours 2 – Cycle de vie de logicielsUP – Cycle de vie
  • 99. PHASE D’ÉLABORATIONCapturer la majorité des cas d’utilisationValider l’architecture du systèmeEliminer les facteurs de risquePeut décider de ne pas aller au-delàLivrable : prototype exécutable d’architectureLivrable : un planning détaillé et précis sur la phase de constructionSection 5 – méthodologie up94Cours 2 – Cycle de vie de logicielsUP – Cycle de vie
  • 100. PHASE DE CONSTRUCTIONLa phase la plus longue du projetLe reste du système est développé durant cette phaseChaque itération produit un incrément vers le système finalSection 5 – méthodologie up95Cours 2 – Cycle de vie de logicielsUP – Cycle de vie
  • 101. PHASE DE TRANSITIONLe système est déployé chez les utilisateursLes feedbacks récoltés serviront à améliorer le systèmeSection 5 – méthodologie up96Cours 2 – Cycle de vie de logicielsUP – Cycle de vie
  • 102. Expression de besoinsRecenser les besoins fonctionnels et non fonctionnels du systèmeLe diagramme UML de cas d’utilisation est utilisé pour cette phaseSection 5 – méthodologie up97Cours 2 – Cycle de vie de logicielsUP – Activités
  • 103. AnalyseDétaille les besoins en spécifications détailléesUne ébauche de la conceptionSection 5 – méthodologie up98Cours 2 – Cycle de vie de logicielsUP – Activités
  • 104. ConceptionDécide comment sera construit le système durant l’implémentationDéfinition des sous-systèmes et composantsCréation d’abstractions de la solutionSection 5 – méthodologie up99Cours 2 – Cycle de vie de logicielsUP – Activités
  • 105. ImplémentationTraduire les résultats de la conception en un système opérationnelLivrables : code source, exécutables, …etc.Section 5 – méthodologie up100Cours 2 – Cycle de vie de logicielsUP – Activités
  • 106. TestsVérification et validation des résultats de l’implémentationSection 5 – méthodologie up101Cours 2 – Cycle de vie de logicielsUP – Activités
  • 107. Méthodologie complèteIdentification rapide des risquesLargement adoptée en entrepriseIntégration avec UMLSéparation concise des phases et des livrablesDes formations / livres / tutoriaux disponiblesSection 5 – méthodologie up102Cours 2 – Cycle de vie de logicielsUP – Avantages
  • 108. Cycles de vie de logiciels103Cours iglDébat (05 Mns)La méthode UP est-elle une méthode agile ?
  • 109. C’est une méthode bidimensionnelle, pourquoi ?
  • 110. C’est une méthode itérative et incrémentale, pourquoi ?
  • 111. Pourquoi est-elle largement adoptée à votre avis ?Cycles de vie de logiciels104Cours iglSection 6 : Outils de supports (CASE – Computer-Aided Software Engineering)
  • 112. CASE est un nom donné aux logiciels 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éveloppementOutils case105Cours 2 – Cycle de vie de logicielsIntroduction
  • 113. Le développement est essentiellement basé sur l’intelligence humaine, là, les outils CASE ne peuvent pas trop intervenirLe 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.Outils case106Cours 2 – Cycle de vie de logicielsLimite des CASE
  • 114. 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’outilOutils case107Cours 2 – Cycle de vie de logicielsClassification des CASE
  • 115. Outils case108Cours 2 – Cycle de vie de logicielsClassification fonctionnelle
  • 116. Outils case109Cours 2 – Cycle de vie de logicielsClassification fonctionnelle
  • 117. Cycles de vie de logiciels110Cours iglDémonstration : outil de génération de documents
  • 118. Cycles de vie de logiciels111Cours iglDémonstration : outil de gestion de tests unitaires
  • 119. Cycles de vie de logiciels112Cours iglDémonstration : outil de gestion de tests unitaires
  • 120. Cycles de vie de logiciels113Cours iglDébat (05 Mns)Quels sont les outils CASE avec lesquels vous avez déjà travaillé ?
  • 121. Quels sont ceux que vous souhaiteriez découvrir ?Software Engineering Right Edition, Ian Sommerville, Addison Wesley, 2007Software Development and Professional Practice, John Dooley, APress, 2010Software Development Life Cycle (SDLC), Togi Berra, course session 2Rational Unified Process - Best Practices for SoftwareDevelopment Teams, IBM / Rational, 1998bibliographie114Cours 2 – Cycle de vie de logicielsBibliographie