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

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

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

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

Contenu connexe

Tendances

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

Plus de Mohammed Amine Mostefai

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