Méthodologie

d'ingénierie et
d'intégration des
systèmes
Dr. Rim zarrouk
 Objectifs :
Chaque étudiant doit être capable de :
• Maitriser les principes agiles.
• Maitriser le travail en groupe dans le contexte d’un projet Scrum
• Savoir appliquer les règles Scrum dans le contexte d’un projet
réel
Préface • Evaluer les besoins technologiques d'une entreprise lors de
l'implémentation et de la configuration de systèmes intégrés.
Prérequis:

• Ce cours suppose acquises les connaissances de base relatives au

génie logiciel et à l’architecture logicielle.

25/01/2023 2
 • Chapitre 1 : Cycle de vie du logiciel

• Chapitre 2 : Modèle de cycles de vie

Plan • Chapitre 3 : Test logiciel

• Chapitre 4 : ERP (Enterprise Resource Planning)

• Travail individuelle : Configuration d’un mini cas

dans un ERP open source + Exposé et discution

25/01/2023 3
Chapitre 2 : MODÈLES
DE CYCLES DE VIE
Plan

• Modèles classiques (Cascade, V, incrémental, prototypage, spirale …)

• Méthodes agiles (SCRUM, RAD, XP…)

• Processus unifié.

+ TD 1

25/01/2023 5
Les modèles de cycles de vie
1. Modèles classiques

• Modèles linéaires

• modèle en cascade

• modèle en V

• Modèles itératifs

• modèle de développement en spirale

• modèle de développement incrémental

• Modèle par prototypage

2. Modèles de la transformation formelle

3. Modèles agiles : SCRUM, RAD, XP, Kanban, …

4. Modèles orientés objet

• Processus unifié

• 2TUP
25/01/2023 6
 MODÈLES
CLASSIQUES
Linéaires
Le modèle en cascade
• Le cycle de vie en cascade a été décrit par Royce dès 1970.

• Il présente le développement logiciel comme une suite de phases qui

s’enchaînent dans un déroulement linéaire, depuis l’analyse des besoins
jusqu’à la livraison du produit au client.

25/01/2023 8
Le modèle en cascade

25/01/2023 9
Le modèle en cascade
• Chaque étape doit être achevée avant que ne débute la suivante.

• Chaque étape permet d’élaborer des produits intermédiaires

• Chaque fin d’étape est matérialisé par un événement, où s’exerce une activité de contrôle
(Vérification et Validation) afin d’éliminer au plus tôt les anomalies des produits réalisés.

• Le passage à l’étape suivante est conditionné par le résultat de contrôle (acceptation, rejet,
ajournement)

• Les retours en arrière sur les étapes précédentes se limitent à un retour sur l’étape immédiatement
antérieure.

• Adapté aux projets dont les besoins sont clairs dès le début du projet.
25/01/2023 10
Le modèle en cascade: Bilan

• Avantage

• Facile à comprendre

• Inconvénients

• Approche purement séquentielle et « simpliste »

• Il est rare que le client puisse fournir toutes les spécifications dès le début du projet.

• Le client ne reçoit pas de résultats concrets pendant le développement du logiciel

(Problème de l’effet tunnel )

25/01/2023 11
Le modèle en V
• Processus linéaire dérivé du modèle de la cascade;

• En plus de l’enchaînement des étapes successives, ce cycle met en relation

des étapes plus éloignées.

25/01/2023 12
Le modèle en V

25/01/2023 13
Modèle en V: principe
• Les premières étapes du cycle doivent préparer les dernières étapes,
essentiellement les activités de vérification et de validation.

• On insiste sur la partie test, réalisée à chaque étape et permettant de s’assurer

que le composant correspond à la description

• obligation de concevoir les jeux de test et leurs résultats ;

• réflexion et retour sur la description en cours.

25/01/2023 14
Modèle en V: principe
• Deux sortes de dépendances entre étapes :

• Traits continus : correspondent à l’enchaînement du modèle de la cascade, les

étapes se déroulent séquentiellement en suivant le V de gauche à droite

• Traits non continus : Une partie des résultats de l’étape de départ est utilisée
directement par l’étape d’arrivée.

• Par exemple : à l’issue de la conception globale, le protocole d’intégration et

les jeux de tests d’intégration doivent être complètement décrits.

25/01/2023 15
Modèle en V: Avantages
• Une meilleure spécification

• évite d’énoncer une propriété qu’il est impossible de vérifier objectivement

une fois le logiciel réalisé.

• Prévenir les erreurs

• l’obligation de concevoir les jeux de tests et leurs résultats oblige à une

réflexion et à des retours sur la description en cours.

• Une meilleure planification du projet:

• Les étapes de la branche droite du V peuvent être mieux préparés et planifiés.

25/01/2023 16
Modèle en V: Inconvénients
• Le client ne reçoit pas de résultats concrets pendant le développement du
logiciel

• Les validations intermédiaires n’empêchent pas la transmission des

insuffisances des étapes précédentes.

• Adapté aux problèmes sans zones d’ombre

• Idéal quand les besoins sont bien connus et quand l’analyse et la

conception sont claires.

25/01/2023 17
Cycle de vie linéaire
• Avantages
• Une meilleure solution si l’on maitrise le type de projet.
• Documentation abondante.
• Inconvénients
• Des difficultés surviennent s’il est impossible d’obtenir de l’utilisateur un énoncé
complet et cohérent de ses besoins.
§ Il est irréaliste de penser que l’on peut définir dès le départ, complètement et dans
le détail, ce que l’on veut réaliser et les résultats intermédiaires attendus.
• Il n’y a pas de feedback avant la livraison au client.
• L’environnement du logiciel peut être tellement mouvant qu’il est difficile de
construire le logiciel sur des spécifications figées.
§ Ils ne reflètent pas la façon dont le code est développé.
• Manque de flexibilité pour gérer les imprévus.

25/01/2023 18
 MODÈLES
CLASSIQUES
Par prototypages
Modèle du prototypage
• Prototype = une version de tout ou d’une partie d’un logiciel, facile à mettre en œuvre et à modifier.

• Il permet de vérifier rapidement certaines fonctionnalités en sacrifiant la précision des autres.

• Il n’est pas construit avec les mêmes contraintes de qualité que le logiciel final.

• Prototypage = technique importante de validation des besoins.

• Technique souvent utilisé pour la validation des spécifications MAIS peut être aussi utilisé à différentes
étapes du cycle de vie.

• Selon l’étape, les objectifs du prototype sont différents.

§Pour montrer la faisabilité
§ Valider les interfaces utilisateurs
§ etc.

25/01/2023 20
Modèle du prototypage
• Initialement, les spécifications données par le client sont d’ordre général ;

• Raffinement des spécifications, des fonctionnalités et des performances par des prototypes
successifs.

• Quand le client donne son accord, le développement suit souvent un cycle de vie linéaire.

25/01/2023 21
Modèle du prototypage: Avantages
• Pour le client:
Une approche où domine l’écoute total du client.

§Le client reçoit des résultats tangibles rapidement ;

§Le client peut exprimer ses besoins plus facilement;

§Le client peut changer d’avis sans conséquences dramatiques.

• Pour l’utilisateur:
§ Expérimentation rapide par les utilisateurs et feedback immédiat.

§ Former les utilisateurs avant la livraison du système final.

• Pour l’équipe de développement:

§Meilleure clarification des spécifications

§Amélioration de la COMMUNICATION entre d’une part le client et l’analyste, d’autre part l’analyste et le
concepteur
25/01/2023 22
Modèle du prototypage: Inconvénients
• Impatience du client qui croit avoir un logiciel final.

• Problème relatif à la gestion de projet (planification, estimation

des coûts, etc.)

25/01/2023 23
 MODÈLES
CLASSIQUES
itératifs
Modèle incrémental
• A été proposé dans les années 80
• Propose un développement du logiciel par morceaux, lesquels sont
livrés successivement au client, en venant se greffer à un noyau
logiciel.

25/01/2023 25
Modèle incrémental

25/01/2023 26
Modèle incrémental
• Un seul sous-ensemble des composants est développé à la fois
§ Un logiciel noyau est tout d’abord développé puis,
§ Des incréments sont successivement développés et intégrés
• Permet d’éviter de tout concevoir, de tout coder et de tout tester
• Les spécifications du logiciel sont figées et connues, l’étape de conception globale
est terminée.
• Certains modèles proposent de développer les différents incréments en parallèle:

25/01/2023 27
Modèle incrémental: Avantages
• Fournir des livraisons et des mises en service après chaque
intégration d’incrément ;
§ faire accepter progressivement un logiciel par les utilisateurs
• Intégration allégée: les intégrations et leurs tests sont progressifs ;
• Maintenance allégée (par incrément)

25/01/2023 28
Modèle incrémental: Inconvénients
• Un risque majeur de ce modèle est de voir remettre en cause le
noyau ou les incréments précédents (définition globale des
incréments et de leurs interactions dès le début du projet).

• Complexité croissante de l’intégration de nouveaux incréments;

• Pour chaque version à développer après la 1ère version livrée, il

faut arbitrer entre les demandes de correction et le développement
des nouvelles fonctionnalités.

25/01/2023 29
Modèle en spirale
• A été proposé par Boehm en 1988
• Il met l’accent sur une activité particulière : l’analyse et la gestion des
risques
• Tient compte de la possibilité de réévaluer les risques et les gérer en
cours de développement.
• Le développement présente quatre grandes phases qui se succèdent au
fur et à mesure de la construction de la spirale,
• Au dernier tour de la spirale, le produit est totalement défini, les risques
résolus et le produit développé.

25/01/2023 30
Modèle en spirale

25/01/2023 31
Modèle en spirale

25/01/2023 32
Modèle en spirale

• Les activités du projet commencent par la spirale la plus profonde

• Chaque tour passe par les régions tâches

• Un tour du modèle résulte en un prototype

• On obtient un raffinement du produit en parcourant plusieurs tours du

modèle

25/01/2023 33
Modèle en spirale
• Le modèle est divisé en « région-tâches »:
• Détermination des objectifs du cycle, des alternatives pour les atteindre et des
contraintes ; à partir de l'analyse préliminaire des besoins ou des résultats des
cycles précédents;
• Analyse des risques, évaluation des alternatives à partir de maquettage et/ou
prototypage;
• Développement et vérification de la solution retenue(un modèle cascade ou en
V peut être utilisé ici);
• Revue des résultats et planification du cycle suivant.

25/01/2023 34
Modèle en spirale: EXEMPLE DE RISQUES
• Risques humains
• défaillance du personnel ; surestimation des compétences; manque de motivation.
• Risques processus
• pas de gestion de projet; calendrier et budget irréalistes ;
• calendrier abandonné sous la pression des clients;
• tâches externes défaillantes ; validité des besoins ;
• développement de fonctions ou/et d’interfaces utilisateurs inappropriées.
• Risques technologiques
• changement de technologie en cours de route;
• problèmes de performance;
• exigences démesurées par rapport à la technologie.

25/01/2023 35
Modèle en spirale: exemple

25/01/2023 36
Modèle en spirale: application
• Le modèle en spirale s'applique essentiellement en interne, lorsque les
clients et les fournisseurs font partie de la même entreprise.

• Dans une relation client-fournisseur ordinaire, un contrat doit être signé

donc l'effort doit être estimé à l'avance:
• Ne pas appliquer le modèle en spirale

• Ou bien, il doit être adapté en signant des contrats partiels pour chaque itération.

25/01/2023 37
Modèle en spirale: Bilan
• Avantages
• Limitation du risque à chaque itération;

• Modèle réaliste et naturel;

• Validation concrète et non sur documents (prototypage);

• Conserve le caractère « étapiste » du modèle en cascade mais l’intègre dans une

approche itérative.

• Inconvénients
• Il est difficile de faire comprendre au client le mode d’opération de ce modèle;

• L’évaluation des risques exige une expertise spécifique;

25/01/2023 38
• Modèle moins expérimenté que les autres.
Modèles agiles
Modèles agiles
• Agilité = la capacité d’une organisation à créer de la valeur et à ravir son client, tout en favorisant
et en s’adaptant -à temps- aux changements de son environnement.

• Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit
collaboratif.

Les méthodes agiles:

§se veulent plus pragmatiques que les méthodes classiques.

§ impliquent au maximum le client et permettent une grande réactivité à ses demandes.

§ visent la satisfaction réelle du client en priorité aux termes d'un contrat de développement.

25/01/2023 40
Valeurs de l’agilité
• Un peu d’historique

• Dans le début des années 1980, une méthode de développement rapide d’application (le RAD) a été proposée. Elle a
été reprise en 1991 pour l’adapter au système français (RAD2).

• En 1994, en Grande-Bretagne, DSDM, équivalente au RAD2, a été proposée

• Dans la seconde moitié des années 90, une dizaine de méthodes agiles ont vu le jour (exples: « Extreme programming
» et SCRUM)

• En 2001-2017 grands noms du développement logiciel se sont réunis aux USA et ont réussi à extraire de leurs concepts
respectifs des critères pour définir une nouvelle façon de développer des logiciels.

• A l’issue de cette réunion est né le «Manifeste Agile» ( 4 valeurs fondamentales et 12 principes de fonctionnement).

• http://agilemanifesto.org/iso/fr/

25/01/2023 41
Valeurs de l’agilité

25/01/2023 42
Valeurs de l’agilité
1.Priorité aux personnes et aux interactions par rapport aux procédures et
aux outils …

• Ce sont les individus, leur expertise, l’esprit d’équipe (plutôt que les
processus et les outils) qui font la valeur du travail accompli:
§ Les processus qui définissent ce que doit faire chaque personne brident le potentiel
caché derrière chacun.
§ Faire interagir les gens au maximum permet d'améliorer grandement l'efficacité et
la qualité du travail fourni.

25/01/2023 43
Valeurs de l’agilité
2. Priorité aux applications fonctionnelles opérationnelles par rapport à une
documentation pléthorique

• Dans les méthodes Agiles, un seul critère permet de mesurer l'avancement d'un
projet : le logiciel qui fonctionne.
• La documentation n'est qu'un support concret qui aide à produire le logiciel.

• Les processus lourds génèrent une documentation exhaustive avec tous ses
inconvénients : ambiguïté du langage, coût de la rédaction, coût du maintien en
accord avec la réalité, etc.

25/01/2023 44
Valeurs de l’agilité
3. Priorité à la collaboration avec le client par rapport à la négociation de contrats

• Sortir de la guerre client/fournisseur et penser en équipe qui veut atteindre un but

commun pour réussir le projet.

• Le client devient un partenaire qui participe au projet pour donner régulièrement

son feedback.

25/01/2023 45
Valeurs de l’agilité
4. Priorité à l’acceptation et la réactivité au changement par rapport au suivi d’un
plan.

• Le planning est flexible pour accepter les modifications nécessaires.

§ Lorsqu’un plan est défini, l’équipe essaie de s’y tenir et ne fait pas attention à des
évènements extérieurs qui peuvent arriver à tout moment du projet.

§Le planning strict est à l'origine des conflits client/fournisseur classiques sur les
délais de livraison.

§Pour le client, pouvoir adapter les besoins en cours de projet est un atout
concurrentiel.

25/01/2023 46
Méthode
Classique
VS
Méthode
Agile

25/01/2023 47
Modèle agiles
• Parmi ces modèles, on trouve :
• SCRUM
• ASD (Adaptative Software Development)
• Crystal
• FDD (Feature Driven Development)
• DSDM (Dynamic Systems Development Method)
• AM (Agile Modeling)
• XP (eXtreme Programming)
• Kanban
• Ces méthodes sont regroupées par l’Agile Alliance
• www.AgileAlliance.org
25/01/2023 52
LES MÉTHODES «AGILE» DISPONIBLES

25/01/2023 53
SCRUM
Un modèle agile: SCRUM
• SCRUM a été formalisé en 1995 par:
• Jeff Sutherland http://jeffsutherland.com/
• KenSchwaber http://kenschwaber.wordpress.com/

25/01/2023 55
Un modèle agile: SCRUM
• Le coeur de Scrum est un sprint : un bloc de temps d’un mois ou moins durant lequel un incrément
du produit est réalisé.

25/01/2023 56
Un modèle agile: SCRUM
• Il est défini par ses créateurs comme un « Framework » (Cadre de
travail permettant de répondre à des problèmes complexes et
changeants tout en livrant de manière productive et créative des
produits de la plus grande valeur possible)
• Scrum est:
• Léger (Lightweight)
• Facile à comprendre (Simple to understand)
• Difficile à maîtriser (Extremely difficult to master)

25/01/2023 57
Un modèle agile: SCRUM

25/01/2023 58
Un modèle agile: SCRUM

25/01/2023 59
SCRUM: rôles
• Scrum master
• responsable devait de veiller à ce que le processus soit bien
compris et suivie
• Product Owner
• responsable de maximiser la valeur du travail qui fait l'équipe
scrum
• L'équipe
• responsable de la réalisation des travaux

25/01/2023 60
SCRUM: rôles
• Le scrum master
• responsable de la mise en œuvre des valeurs et des pratiques de

scrum.

• éliminer les obstacles.

• S'assurer que l'équipe est entièrement fonctionnelle et productif.

• Permettre les la coordination entre les divers rôles et fonctions.

• Protéger l'équipe de toute intervention extérieure

25/01/2023 61
SCRUM: rôles
• Le product owner
• définir les caractéristiques du produit.
• Décider de la date de livraison et le contenu.
• Responsable de retour sur investissement du produit.
• Prioriser les fonctions conforment à leur valeur business
• ajuster les fonctions et leur priorité pour chaque sprint
• accepter ou rejeter les résultats
25/01/2023 62
SCRUM: rôles
• L'équipe
• ne comporte pas de rôles prédéfinis pour ses membres

• Il n'y a pas non plus de notion de hiérarchie interne :

§ toutes les décisions sont prises ensemble

§ personne ne donne d'ordre à l'équipe sur sa façon de procéder.

• L'équipe s'adresse directement au Product Owner

• La composition de l’équipe doit rester stable durant le sprint (au minimum).

25/01/2023 63
Scrum: les artifacts
• Product backlog :
• une liste priorisée de tout ce que ce qui peut être nécessaire dans le produit

• sprint backlog :
• une liste des tâches nécessaires pour transformer le backlog de produit dans
un incrément de produit potentiellement final.

• Release burndown:
• mesure le backlog des produits restant dans le temps

• Sprint burndown:
• mesure le sprint backlog restant durant le sprint

25/01/2023 64
SCRUM: Backlog du produit
• Le backlog du produit est une liste de user stories. Le product owner doit les ordonner par
priorité et estimer le temps nécessaire pour chaque user story en affectant des story points.

• Story point: Unité de mesure exprimant une estimation de l’effort demandé pour effectuer
une tâche.

• Exemple

§ Story point = 1 >>> quelques heures

§ Story point = 2 >>>1 jour

§ Etc.

• Dans un sprint ne pas mettre les stories points > 5 -> diviser les user stories

25/01/2023 65
SCRUM: Backlog du produit
• Syntaxe de construction des User Stories :

§User Stories :

§ En tant que <Rôle> (As a <User role>)

§ Je souhaite pouvoir <Fonctionnalité> (I want to <Functionality>)

§ Afin de <Bénéfice> (so that <value>)

25/01/2023 66
SCRUM: Backlog du produit

25/01/2023 67
SCRUM: User Stories

25/01/2023 68
SCRUM: BurnDown Chart

25/01/2023 69
 SCRUM:
bilan

25/01/2023 70
Les réunions SCRUM

• La planification de sprint consiste à déterminer le travail à effectuer durant le

sprint.

• Elle est limitée à 8 heures pour un sprint d’un mois.

• Elle s’agit de répondre aux questions suivantes:

• Qu’est-ce qui peut être terminé au cours de ce sprint ?

• Comment sera effectué le travail choisi ?

25/01/2023 71
Les réunions SCRUM
• Mêlée quotidienne

• Destinée à permettre à l’équipe de développement de synchroniser

ses activités et planifier les prochaines 24 heures.

• Tous les jours, 15 minutes, même heure, même endroit.

• Chaque membre de l’équipe de développement décrit:

§Ce qu’il a réalisé depuis la dernière réunion ;

§Ce qu’il réalisera avant la prochaine réunion ;

§ Les difficultés qu’il rencontre.

25/01/2023 72
Les réunions SCRUM
• Revue de sprint

• L'équipe Scrum (PO+SM+E) et les intervenants échangent sur ce qui a été

fait durant le sprint.

• Inspecter l’incrément du produit et adapter le carnet de produit si

nécessaire.

• Pour un sprint d’un mois, cette rencontre est limitée à un bloc de temps de
quatre heures.

§ Sprints plus courts: allouer proportionnellement moins de temps.

25/01/2023 73
Les réunions SCRUM
• Rétrospective du sprint
• Inspecter la manière dont le dernier sprint s’est déroulé en ce qui concerne les
personnes, les relations, les processus et les outils ;

• Identifier et ordonner les éléments majeurs qui se sont bien déroulés et les
améliorations potentielles ;

• Créer un plan pour améliorer les processus de travail de l'équipe Scrum

(PO+SM+E).

• Pour un sprint d’un mois, cette rencontre est limitée à un bloc de de trois heures.

25/01/2023 74
SCRUM: Taille de l’équipe de développement
• Une équipe de développement de taille optimale est assez petite pour demeurer agile et assez grande

pour effectuer du travail significatif.

§ Moins de trois membres dans l'équipe de développement diminue les interactions et entraîne des gains

de productivité moindres.

§Une équipe de développement trop petite risque de rencontrer des contraintes de compétences.

§Plus de neuf membres exige trop de coordination.

• Les grandes équipes de développement génèrent trop de complexité pour être gérées par un processus

empirique.

§ Processus empirique : basé sur l'expérience, nécessite une bonne visibilité, des inspections fréquentes et

des adaptations aux plans.

25/01/2023 75
SCRUM: Bilan
• Avantages

• Règles définies clairement

• Souplesse : répondre au changement, modifier le projet et les livrables à tout

moment

• Contrôle quotidien : coût; planning; fonctionnalités; et qualité.

• Partage de connaissances : améliorer la productivité

• Résultat conforme aux attentes

• Inconvénients

• Grande disponibilité de tous les acteurs

25/01/2023 76
KANBAN
KANBAN
• Mot signifiant étiquette (ou petite
fiche)

• Pratique basée sur l’utilisation

d’étiquette (post-it) pour
matérialiser les informations sur
le processus

25/01/2023 78
KANBAN-Principes
• C’est une méthode inventé à la fin des années 1950 dans les entreprises TOYOTA.

• Une bonne organisation de la chaîne de production entre deux postes de travail

• Une simple fiche cartonnée fixée sur les bacs de pièces dans une ligne d'assemblage ou une
zone de stockage

• Les objectifs de Toyota :

• Limite la production du poste amont aux besoins exacts du poste aval

• Le nombre de kanban en circulation doit être limité pour éviter la constitution d'encours
trop importants

25/01/2023 79
KANBAN-Principes
• Le problème à résoudre est un workflow
• La solution consiste à le visualiser

• Diviser le travail (comme dans Scrum…)

• Décrire chaque élément sur une fiche et la mettre au mur (tableau, board)
• Tracer des colonnes, donnez leur le nom des étapes du workflow
• Placer les éléments du travail

• En tant que développeur

• Choisir ce qui est à faire en fonction de ses compétences ou missions
• Faire ce qui est « en cours »
• Mettre à jour le tableau Kanban
25/01/2023 80
KANBAN-Principes
• Au minimum
• TO DO
• IN PROGRESS
• DONE
• Au maximum
• TO DO
• CHOSEN
• DEVELOPMENT
• TESTS
• DELIVERY
• DONE

25/01/2023 81
KANBAN-Principes

25/01/2023 82
KANBAN-Principes

25/01/2023 83
KANBAN-Principes
• Est ce qu’on peut avoir 500 fichiers dans « In progress » ou « to do » ?

• Limiter le TAF (Travail AFaire / WIP : Work in Progress)

• Fixer des bornes au nombre d’éléments dans chaque étape

• Mesurer le temps de cycle (lead time): C’est le temps moyen pour traiter complètement un
élément, c’est à dire le faire passer par toutes les étapes du workflow

• Optimiser le processus en réduisant le temps de cycle et en le rendant prévisible

• Planning Poker

• Fibonacci

25/01/2023 84
SCRUM vs KANBAN
• Scrum est plus normatif que Kanban.
• Scrum impose des rôles.
• Scrum impose des itérations de durée fixe.
• Kanban limite le TAF à chaque étape du workflow, Scrum limite
• le TAF à chaque itération.
• Les deux sont empiriques.
• Scrum autorise peu de changement dans une itération.
• Le tableau Scrum est réinitialisé à chaque début d'itération.
• Avec Kanban, le tableau est généralement persistant : vous n’avez donc pas besoin de le réinitialiser et
de démarrer avec autre chose.
• Scrum impose des équipes multidisciplinaires
• Les deux permettent de travailler sur plusieurs produits simultanément
• ….
25/01/2023 85
 Modèles
orientées objet
Modèles orientées objet
• Le développement orienté objet conduit à des architectures logicielles fondées sur les
objets (plutôt que sur les fonctions qu'il est censé réaliser)

• Pour la modélisation orientée objet, UML est le standard.

• UML n’est pas une méthode mais un langage : définit des diagrammes et des notations
mais n’impose pas de méthode.

• Le Processus Unifié (PU) a été proposé afin de compléter UML avec une méthode

25/01/2023 87
Processus
unifié
Processus unifié: un modèle OO

• PU est une méthode générique de développement de logiciels

• Générique = pouvant être adaptée à une large classe de systèmes

logiciels.

• Il couvre l’ensemble des activités d’un projet logiciel à travers une

panoplie de principes génériques, adaptables en fonction des spécificités
des projets.

25/01/2023 89
PU: caractéristiques

1. PU utilise le langage UML;

2. PU est conduit par les cas d’utilisation;

3. PU est centré sur l’architecture;

4. PU est itératif et incrémental.

5. PU gère les risques

25/01/2023 90
PU: caractéristiques
• PU est conduit par les cas d’utilisation

• Le processus de développement est centré sur l’utilisateur.

• Toutes les activités, de l’analyse des besoins jusqu’aux tests sont guidés par
les cas d’utilisation

• A partir des cas d’utilisation, les développeurs créent une série de modèles UML.

25/01/2023 91
PU: caractéristiques
• PU est itératif et incrémental

• Découpe le projet en “mini-projet” : des ITÉRATIONS qui donne lieu à des INCRÉMENTS.

• Les itérations désignent des étapes de l’enchaînement des activités tandis que les incréments
correspondent à des stades de développement du produit.

• Une itération reprend les livrables dans l’état où les a laissé l’itération précédente et les enrichit
progressivement (incrémental).

• PU est piloté par les risques

• Chaque itération comprend un certain nombre de cas d’utilisation et doit traiter en priorité les
risques majeurs.

25/01/2023 92
PU: caractéristiques
• PU est centré sur l’architecture
• Tous les intervenants au projet de développement, du chef projet au programmeur doivent
s’accorder sur la vision commune du système à produire : l’architecture.
• L’architecture regroupe les différentes vues du système qui doit être construit.
• Elle doit prévoir la réalisation de tous les cas d’utilisation.

• Démarche à suivre:
• Créer une ébauche grossière de l’architecture
• Travailler sur les cas d’utilisation représentant les fonctions essentielles.
• Adapter l’architecture pour qu’elle prenne en compte ces cas d’utilisation.
• Sélectionner d’autres cas d’utilisation et refaire de même.
25/01/2023 93
PU: Phases & Activités
• Phase d'Inception: Identification des principaux cas d’utilisation.

• Phase d’élaboration: l’analyse et la conception de la plupart des fonctionnalités du système sont abordés.

• Phase de construction : au cours de laquelle la conception et la réalisation du système sont achevés.

• Phase de transition : est dédiée au test des fonctionnalités du système.

• A chaque phase, un ensemble d’activités est réalisé:

• Capture des besoins

• Analyse

• Conception

• Implémentation

• Tests ...

25/01/2023 96
PU: Phases
• Phase d’inception: Identification des principaux cas d’utilisation.

• Traduit une idée en vision de produit fini et présente une étude de rentabilité pour ce
produit.
• Un modèle simplifié des cas d’utilisation, regroupant les principaux cas d’utilisation ,est
réalisé.

• Une architecture provisoire est réalisée: une ébauche relevant les principaux sous-systèmes.

• Planification en détail de la phase d’élaboration et fourniture d’une estimation du projet dans

son ensemble.

• Identification et hiérarchisation des risques majeurs.

25/01/2023 97
PU: Phases
• Phase d’élaboration: l’analyse et la conception de la plupart des fonctionnalités du
système sont abordés.

• A l’issue de cette phase, le chef de projet doit être en mesure de prévoir les activités et
d’estimer les ressources nécessaires à l’achèvement du projet.

• Cette phase aboutit à l’émergence de la stabilité des cas d’utilisation, d’une architecture
de référence, d’un plan de développement et la maîtrise des risques pour permettre le
respect du contrat.

25/01/2023 98
PU: Bilan
• Avantages
• standard

• aide à gérer la complexité

• permet de diminuer les risques

• meilleure évaluation de l'évolution du produit

• Inconvénients
• peut s’avérer lourd à mettre en place

• peu adapté au projet de petite envergure.

25/01/2023 99
Agile Vs UP
• Points en commun
• Incrémental et itératif
• Division du travail en tâches
• Test continu
• Se focaliser sur la qualité
• Intégration continue
• Maîtriser les changements
25/01/2023
• Points différents
• Comment appliquer le processus
incrémental
• UP est un Framework /Agile est un
ensemble de principes (manifeste)
• Taille des projets
• Agile (petits et moyens projets à) /UP (grands
projets)
• UP est plus lourd en documents et en
artéfacts
• Agile plus flexible aux changements
100
Quelques Instances du PU
• RUP : Rational Unified Process, instanciation par Rational des préceptes UP

• EUP : Enterprise Unified Process, instanciation intégrant les phases de post-implantation.

• XUP : Extreme Unified Process, instanciation hybride intégrant UP avec Extreme

Programming.

• AUP : Agile Unified Process, partie des préceptes UP permettant l’agilité du développement.

• 2TUP : Two Tracks Unified Process, instanciation de UP proposé par Valtech prenant en
compte les aléas et contraintes liées aux changements perpétuels et rapides des SI des
entreprises.

• EssUP : Essential Unified Process, instanciation de UP proposé par Ivar Jacobson Consulting
qui propose une mouture du processus unifié qui intègre certains concepts de l’agilité.

25/01/2023 101
Un modèle OO: 2TUP

• Pourquoi 2TUP?
Réponse aux contraintes de
changement continue imposées
aux systèmes d’information de
l’entreprise.

25/01/2023 102
2TUP et UML

25/01/2023 103
2TUP: Bilan
• Avantages
• Itératif

• Cible des projets de toutes tailles

• Donne une place importante à la technologie et à la gestion des risques

• Inconvénients
• Plutôt superficiel sur les phases situées en aval du développement: support, maintenance

25/01/2023 104
CONCLUSION
• Quel est le meilleur cycle de vie?

• Y-a-t-il des critères de choix ?

25/01/2023 105
CONCLUSION
• Il n’y a pas de modèle idéal car tout dépend des circonstances: type du projet, taille du projet,
taille de l’équipe,…

• Le modèle en cascade ou en V est risqué pour les développements innovants car les spécifications et
la conception risquent d’être inadéquats et souvent remis en cause.

• Le modèle incrémental est risqué car il ne donne pas beaucoup de visibilité sur le processus complet.

• Le modèle en spirale est un canevas plus général qui inclut l’évaluation des risques.

• Souvent, un même projet peut mêler différentes approches, comme le prototypage pour les sous
systèmes à haut risque et la cascade pour les sous systèmes bien connus et à faible risque.

25/01/2023 106
Gestion de projet - iceScrum

25/01/2023 107
Gestion de projet - iceScrum

25/01/2023 108
Gestion de projet - iceScrum

25/01/2023 109
Gestion de projet - iceScrum

25/01/2023 110
Gestion de projet - iceScrum

25/01/2023 111
Gestion de projet - iceScrum

25/01/2023 112
 Méthodologie d'ingénierie et
d'intégration des systèmes
Merci

Chapitre 2 : MODÈLES DE CYCLES DE VIE

Dr. Rim zarrouk

25/01/2023 113