NOTES DE COURS DE GENIE LOGICIEL

Introduction générale

1. Définition des concepts

- Le Génie Logiciel : est une capacité nécessaire permettant de trouver solution à

un cas spécifique. Un génie, est une personne qui développe les capacités
capables de trouver solution à un problème spécifique.

- Un avant-projet : est un ensemble d’éléments pouvant aider à concevoir un

projet informatique. Pour bâtir une maison en construction, nous aurons besoin
de : la fondation ; élévation des murs ; toitures, finissage ; comme nous nous
basons dans le domaine de la construction afin de concevoir un projet
informatique, nous aurons besoin de : avant-projet, les modèles conceptuels
(MCC, MCD, MCT), MLD et MOT).

- Le logiciel : est la partie douce, intelligente de l’ordinateur. C’est aussi un

ensemble des programmes (ayant à son sein les programmes) qui permet à un
ordinateur ou à un système de d’exécuter une tâche bien précise.

- Génie Logiciel : l’ensemble d’aptitudes, des méthodes permettant de produire

au moyen d’une équipe des personnes, des programmes réalisant des tâches
spécifiques mais, conduisant à un objectif unique. Actuellement, le génie
logiciel est devenu une branche importante de de l’informatique.

Le génie logiciel est né en le 7-11 Octobre 1966-1969 à Garmish-Partern

Kirchen. Est créé à cause de la crise de logiciel (une période qui part de 1966-1969).
Etait dit au fait que :
 La production des mauvais logiciels et
 L’indisponibilité des personnes compétentes qui mettaient les logiciels
en place.

- Ingénierie logiciel : ensemble des fonctions qui mènent à la conception, aux

études, à l’achet et au contrôle de fabrication ainsi qu’à la construction et mise
en œuvre des logiciels de type industriel.

2. LE BUT DE GENIE LOGICIEL

Le génie logiciel a pour but :

1. * De permettre à chacun de concevoir un programme (architecture logiciel)
en fonction des solutions attendues en utilisant d’autres personnes.
* Capable de produire des différents composants ayant chacun un but
approprié mais, qui réalise l’architecture logicielle.
2. Coder et valider les algorithmes issus de ses différents résultats obtenus ;
3. Maintenir méthodiquement les programmes issus de ses algorithmes.
Les étapes de cette conception sont entre autres :
1. Identification : c’est la dénomination de différents composants sui forment
notre logiciel.
2. Organisation : l’organisation (décomposition) ou un développement qui
permet d’aller de données vers les résultats.
3. La spécification : c’est la description des actions et des objets qui constituent
les éléments de l’organisation. Donc, elle est trop capitale car c’est sur elle que
les algorithmes suivent.

NOTA : Faire le génie logiciel, c’est : identifier, organiser et spécifier c’est-à-dire, les
trois étapes ou phases ci-haut.
4.

CHAP I MODELISATION DES PROJETS INFORMATIQUES

1. Idée du projet
L’idée est le premier stade d’un projet informatique. Elle consiste à imaginer une
nouvelle idée qui peut être :
- Une Nouvelle fonctionnalité
- Une Restructuration
- Une Simplification
- Une Automatisation
- Une Intégration
- Une Analogie (Comparaison)
- Une Globalisation.
2. Elaboration d’un concept
La plupart des systèmes commencent par des idées vagues nécessitant d’être étoffées.
Pour cela, on répond aux question suivantes :
- A qui l’application est elle destinée (destinataire)
- L’application résoudra quel problème (champ d’application)
- Les conditions d’utilisation de l’application (comment l’application complète
celles existantes)
- Quand l’application est elle attendue (donne les aspects temporels)
- Pourquoi l’application est elle attendue (business plan, …)
- Comment l’application fonctionnera-t-elle (étude de faisabilité du problème).

3. ETAPES D’UN PROJET

Une étape est une thématique regroupant un ensemble d’action à entreprendre pour
répondre à un besoin défini dans des délais fixés
• Phase préparatoire (avant projet ou ensemble d’étapes préparatoires nécessaire
au lancement du projet pour aboutir à la mise au point des documents
contractuels)
* étude d’opportunité : étudier la demande, décider de sa viabilité, …
* étude de faisabilité : ensemble d’analyses économiques, organisationnelles et
techniques
* cahier de charges : (document le plus important car référence obligée de tout
 développement
• Analyse (liste les résultats attendus en termes de fonctionnalité, de
performance, de robustesse, de maintenance, de sécurité, d’extensibilité, etc.,
l’accent est mis sur ce qui doit être fait, le quoi, indépendamment de la manière
de le faire)
• Conception (produire les diagrammes de classes et des cas d’utilisation qui
serviront à l’implémentation)
• Implémentation (développer l’application)
• Test (s’assurer que le programme répond bien au cahier des charges)
• Déploiement (fournir l’application aux utilisateurs finaux, communiquer,
former, aider, assister)
• Maintenir (processus de remplacement effectif de l’application)
• Suivi (vérifier sir les agents formés appliquent correctement les tâches
dévolues)
4. METHODOLOGIE
Une méthodologie de développement des logiciels est un ensemble de méthodes ou
des étapes nécessaires pour construire des logiciels selon un processus industriel de
production. C’est-à-dire, elle doit s’intéresser au problème de CONCEPTION, de
CODAGE, de VALIDATION et de MAINTENANCE de l’architecture logicielle ou
de ces composants. Vu que le nombre des problèmes à résoudre est quasi infinie,
aucune méthodologie n’est adaptée à tous les problèmes, d’où on parle des
METHODOLOGIES DE DEVELOPPEMENT DE LOGICIEL (ou de
MODELISATION)
MODELE
C’est Procédé de production établi comme une suite de descriptions de plus en plus
précises et de plus en plus proches d’un programme exécutable et de sa documentation
ou une représentation abstraite et simplifiée d’une entité du monde réel en vue de le
décrire, de l’expliquer ou de le prévoir
• Pourquoi modéliser :
- mieux comprendre le fonctionnement du système avant sa réalisation,
- mieux repartir les tâches pour automatiser certaines d’entre elles,
- un facteur de réduction des coûts et des détails
• Qui doit modéliser :
- le MOE (car les priorités de la MOE résident dans le fonctionnement de la
plate-forme
informatique
- il était préférable que le MOA réalise la modélisation pour qu’il puisse, en tant
que maître
d’ouvrage, insérer ses propres concepts
• Pièges de la modélisation
- paralysie de l’analyse (analystes non développeurs, …)
- modélisation en parallèle (présence des styles différents, …)
- raisonnement abstrait impossible (faiblesse des nombreuses personnes)
- périmètre trop vaste
- absence de la documentation
- absence de revues techniques
4. METHODOLOGIE (cycle de vie)
• Cycle de vie d’un logiciel
Le cycle de vie est la période de temps s’étalant du début à la fin du processus du
logiciel.
Il commence avec la proposition ou la décision de développer un logiciel et se termine
avec sa mise hors service.
Le génie logiciel a pour objet :
- l’étude,
- la modélisation et
- la mise en pratique de ce software process.
C’est le processus de développement d’un logiciel fournit une base – une collection de
techniques et de notations prédéfinies – pour la production organisée des logiciels.
Le développement et l’évolution d’un logiciel doit être vu comme un processus, appelé
abusivement processus du logiciel ou software process .
Ce processus comprend des sous processus qui communiquent entre eux et dont
certains évoluent en parallèle.
Chaque processus étant caractérisé par ses conditions de déclenchement, les activités
déployées, les ressources utilisées, les produits résultants et ses critères de terminaison.
Le processus du logiciel peut être l’objet d’observations (qu’est-ce qui se fait dans la
pratique?) ou d’études théoriques (comment faut-il procéder?).
Il n’existe pas un seul processus du logiciel, ni en pratique, ni en théorie, pour des
raisons multiples :
- diversité des applications informatiques et des logiciels
- disparité entre les méthodes, techniques et outils utilisés pour développer des
logiciels
- différence de « culture » et d’habitude aussi bien des organisations que des
personnes
4. METHODOLOGIE (software process)
Voici le processus que le groupe de travail de l’ISO, a retenu le software life cycle
model suivant :
• Gestion du cycle de vie du logiciel (project management)
- Initiation du projet (project initiation)
- pilotage et suivi du projet (project monitoring and control)
- gestion de qualité du logiciel (software quality management)
• Pré-développement (pre-development)
- besoin de l’utilisateur ou du système (user/system requirement)
- conception du système (system design)
• Développement (développement)
- Besoin en logiciel (software requièrent)
- conception architecture (architectural design)
- conception détaillée (detailed design)
- codage (code)
- intégration (integration)
- réception du logiciel (software acceptance)
- intégration du système (system integration)
- test de terrain (field test)
 • Post développement (post development)
- installation (installation and checkout)
- exploitation (operation)
- maintenance et support du logiciel (software maintenance and support)
- retrait -retirement)
• Processus globaux (integral precesses)
- vérification et validation (verification and validation)
- gestion de la configuration du logiciel (software configuration management)
- développement de la documentation (documentation développement)
- formation (training)
Cet ensemble peut être résumé en quatre blocs à savoir :
- l’avant-projet
- le développement
- l’exploitation et maintenance et enfin
- le retrait

• DIFFERENTS MODELES DE CYCLE DE VIE (software process)

1. MODELE EN CHUTE D’EAU (modèle en cascades)
Dans ce modèle, tous les éléments d’un niveau sont déversés dans le niveau d’en bas.

Ce modèle exige que les différents entrant dans la réalisation d’un logiciel
Ce modèle est simple.
Il présente comme inconvénients le fait que les erreurs ne sont découverts qu’à la fin
du processus
* Validation limitée à un pas d’itération
* augmentation des risques : erreur d’analyse ou de conception très coûteuse si
détectée trop tard !
* Difficile d’effectuer des modifications en cours de route
* Solution limitée aux petits projets
* Bien adapté lorsque les besoins sont clairement identifiés et stables 
* les risques sont bien délimités dès le début du projet - projet court avec peu de
participants
* Souvent abandonné au profit du modèle en « V », plus récent, qui présente une
articulation plus réaliste entre l’activité de réalisation et celle de validation-vérification

2. LE MODELE EN V

* Un modèle toujours séquentiel…

* Prédominance de la documentation sur l’intégration : validation tardive du système
par lui-même
* Les validations intermédiaires n’empêchent pas la transmission des insuffisances des
étapes précédentes
* Manque d’adaptibilité
* Maintenance non intégrée : syndrome du logiciel jetable
* Idéal quand les besoins sont bien connus, quand l’analyse et la conception sont
claires

* Un modèle toujours séquentiel…

* Prédominance de la documentation sur l’intégration : validation tardive du système
par lui-même
* Les validations intermédiaires n’empêchent pas la transmission des insuffisances des
étapes précédentes
* Manque d’adaptibilité
* Maintenance non intégrée : syndrome du logiciel jetable
* Idéal quand les besoins sont bien connus, quand l’analyse et la conception sont
claires
 • Avantages du modèle en spirale :
- Le logiciel est produit tôt dans le cycle de vie du logiciel.
- La gestion des risques est l’un des avantages importants du modèle Spiral, c’est le
meilleur modèle de développement à suivre en raison de l’analyse des risques et de la
gestion des risques à chaque phase.
- Flexibilité dans les exigences. Dans ce modèle, nous pouvons facilement modifier les
exigences lors des phases ultérieures et les intégrer avec précision. De plus, des
fonctionnalités supplémentaires peuvent être ajoutées ultérieurement.
- C’est bon pour les grands projets complexes.
- C’est bon pour la satisfaction du client. Nous pouvons impliquer les clients dans le
développement de produits dès les premières phases du développement logiciel. De
plus, le logiciel est produit tôt dans le cycle de vie du logiciel.
- Approbation solide et contrôle de la documentation.
- Il convient aux projets à haut risque, où les besoins de l’entreprise peuvent être
instables. Un produit hautement personnalisé peut être développé à l’aide de cela.

• Inconvénients du modèle en spirale :

• Il ne convient pas aux petits projets car il est coûteux.
• Il est beaucoup plus complexe que les autres modèles SDLC. Le processus est
complexe.
• Trop dépendant de l’analyse des risques et nécessitant une expertise très
spécifique.
• Difficulté dans la gestion du temps. Comme le nombre de phases est inconnu au
début du projet, l’estimation du temps est donc très difficile.
• La spirale peut durer indéfiniment.
• La fin du projet peut ne pas être connue tôt.
• Il ne convient pas aux projets à faible risque.
• Il peut être difficile de définir des jalons objectifs et vérifiables. Un grand
nombre d’étapes intermédiaires nécessitent une documentation excessive.
 • * Modèle itératif basé sur le prototypage
• –   Idée : fournir le plus rapidement possible un prototype exécutable
permettant une validation concrète et non sur document
• –   accent mis sur l’analyse de risque
• –   Progression du projet par incréments successifs de versions successives du
prototype : itérations
• –   1 itération = 1 mini-cycle de vie en cascade
• –   Certains prototypes peuvent être montrés aux clients et utilisateurs. Par
ailleurs, une maquette peut être réalisée préalablement au premier prototype
(Prolog)
• –   La validation par prototypes ne justifie pas l’absence de recours à
la documentation
• Différence clé - cascade vs modèle en spirale
le différence clé entre cascade et modèle itératif est que Le modèle en cascade
est utilisé pour les petits projets et les projets avec des exigences claires,
tandis que le modèle en spirale est utilisé pour les grands projets complexes
nécessitant une analyse continue des risques..

• 4 MODELE ITERATIF ou Développement itératif

C’est un modèle plus souple,
Le développement de ce modèle suit les étapes suivantes :
- Analyse
- conception
- implémentation
- tests
- implantation (livraison du code opérationnel)
- maintenance (élargir le périmètre en incorporant les propriétés (nouvelles) et
les comportement des objets existants et celles des nouveaux )
Plusieurs itérations ont lieu au fur et enbesoins
mesure que le système évolue

• Ce modèle se présente comme suit :

analyse analyse analyse

conception conception conception

implémentation implémentation implémentation

 test test test

* Portée des itérations

La portée du projet consiste à
- déterminer le travail minimum pour une progression pertinente et un bon
objectif
- construire dès le départ les parties vitales ainsi que les fragments de code de
base
fréquemment exécutés par l’application
- s’assurer que vous équilibrez les fonctionnalités du système
La portée du projet consiste à
- déterminer le travail minimum pour une progression pertinente et un bon
objectif
- construire dès le départ les parties vitales ainsi que les fragments de code de
base fréquemment exécutés par l’application
- s’assurer que vous équilibrez les fonctionnalités du système.
* Portée d’une otération
Chaque itération doit proposer, au minimum :
- un retour sur investissement,
- une fonctionnalité ajoutée,
- une interaction utilisateur améliorée,
- une meilleure efficacité,
- une plus haute fiabilité ou une infrastructure renforcée
Il faut éviter le syndrome selon lequel « tout est d’importance égale » et il est inutile
de rendre compte du résultat de chaque itération au client.
Sur le plan développement, il faut :
- conserver l’impulsion
 - rester dans les détails
- assurer que les différents composants d’une application concordent bien
Du point de vue du client l’installation de chaque itération suppose un effort
supplémentaire trop important qui peut être simplifié sur le plan logistique en
combinant plusieurs incréments avant le déploiement.

* Réalisation d’une itération

Étapes de réalisation d’une itération
1ère règle
Chaque itération doit commencer à partir d’un référentiel commun et se terminer
avec un nouveau référentiel
Une équipe doit structurer son travail sur une itération pour pouvoir aller jusqu’au
bout, la vérifier, la tester et l’intégrer au reste du système (la planifier)
2ème règle
Chaque itération doit avoir un exécutable

* Planification de l’itération suivante

Après chaque itération, vous devez évaluer votre progression et revoir la planification
de l’itération suivante.
Questions :
- l’itération réalisée a-t-elle pris plus ou mois de temps que prévue?
- disposez-vous des compétences adéquates parmi vos développeurs?
- le client est-il satisfait de l’avancée du travail
- la prochaine itération soulève-t-elle des problèmes ou des questions
spécifiques?
- le logiciel est-il stable ou devez-vous prévoir du travail supplémentaire ou un
remaniement lors de la prochaine itération?
Si l’itération précédente a réussi, vous pouvez poursuivre votre planification, sinon
n’hésitez à écarter les mauvaises décisions et à effectuer des corrections à mi-
chemin.
L’extensibilité, la maintenance et la viabilité de votre application ne s’obtiendront
qu’au prix d’un développement robuste.
Vous devez recevoir un retour précoce et fréquent des utilisateurs, ils doivent
intérioriser votre travail et réfléchir à ses implications quotidiennes dans leur travail.
En plus, ils doivent vous aider à détecter tout écart par rapport au périmètre du
logiciel ou au développement des itération.

4. METHODOLOGIE (prototypage)
le prototypage rapide permet de développer rapidement une portion de logiciel, de
l’utiliser et de l’évaluer. Vous incorporez ensuite le résultat de votre travail et
recommencez ce cycle. Enfin, vous livrer le prototype final comme s’il s’agissait de
l’application finie ou alors, après quelques prototypes, vous optez pour une autre
approche.
Avantages :
- avantages similaires au développement itératif, mais lui, élimine
fréquemment du code
alors que le développement itératif cherche à l’accumuler,
- lorsqu’il est rapide, il met en avant la communication avec le client et lui
permet
d’exprimer ses exigences,
- il est exploitable pour démontrer la faisabilité technique en cas de
technologie complète
- il offre comme le développement itératif, des points de contrôle fréquents
permettant de
garantir aux clients une bonne avancée du développement
- ils offrent, également aux développeurs un moyen de résoudre des
problèmes ennuyeux
dès le début du développement
Inconvénients :
- il est difficile par un prototype rapide de se débarrasser des codes.

METHODES AGILES
Définition : une méthode agile est une approche itérative et incrémentale, qui est
menée dans l’esprit collaboratif, avec juste ce qu’il faut de formalisme. C’est une
méthode qui génère un produit de haute qualité tout en prenant en compte
l’évolution des besoins des clients.
Le terme agile fait référence à la capacité d’adaptation aux changement de contexte
et aux modifications intervenant pendant le processus de développement
Buts : - visent à réduire le cycle de vie du logiciel (donc à accélérer son
développement) en
intégrant des évaluations des utilisateurs durant le processus de
développement.
- développer une version minimale, puis y intégrer chaque fonctionnalité grâce
à un
processus itératif basé sur une écoute client et des tests
Origines : - instabilité de l’environnement technologique
- le client est souvent dans l’incapacité de définir ses besoins de manière
exhaustive dès
le début du projet
- en 1990, mise à jour de ces méthodes. Deux lignées s’affirment :
* la première dite « unifiée » (UP, RUP, XUP, AUP, EUP, 2TUP, EssUP,
etc)
* le deuxième dite « agile » (XP, Crystal, ASD, Scrum, etc)
(les deux lignées présentent comme principes fondamentaux à la base,
les
éléments de la méthode RAD (Rapid application Development)
- en 2001, 17 personnes ont mis au point le manifeste agile dont la
traduction est :
* les individus et les interactions avant les processus et les outils
* le développement logiciel plutôt avant la documentation
* collaboration avec les clients plutôt que négociation contractuelles
* acceptation du changement plutôt que conformité aux plans.
Avantages : - le client pilote à part entière son projet, d’où, il obtient vite une
première mise en
production de son logiciel
 - les utilisateurs sont associés dès le début du projet afin de maximiser
leurs
appropriation
Classification des méthodes agiles :
il existe plusieurs méthodes dites agiles, mais elles ont un tronc commun de pratique,
ne se différencie que par leurs degrés de formalisme, le poids de la méthodologie
dans la documentation produite, les étapes formelles, les revues, le rythme du projet
et la longueur des itérations.
a) Méthodes unifiées
Le processus unifié (PU ou UP en anglais pour Unified Process) est une méthode de
développement logiciel qui nécessite d’être adaptée à chaque projet qui y a recours.
Elles sont génériques, itératives et incrémentales contrairement aux méthodes
séquentielles comme Merise (ou SADT)
UP est le fruit de la collaboration entre Ivar Jacobson, Grady Booch et James
Rumbaugh, tous trois à l’origine des travaux sur le développement orienté objet et
les techniques de modélisation.
Comme UML, le processus unifié ambitionnait de standardiser des bonnes pratiques
expérimentées ici et là dans l’ingénierie logicielle.
Il faut reconnaitre à Philippe Kruchten d’avoir considérablement enrichi le Processus
Unifié.
Pour certains auteurs, UP n’est pas une méthode « agile », car trop lourde
(modélisation à outrance, nombreuses procédures) et peu flexible.
1) Caractéristiques
huit caractéristiques (dont trois préconisées par UML) essentielles composent le
modèle :
- pilotage par les cas d’utilisation : visant les besoins et exigences de l’utilisateur
- centré sur l’architecture : décomposable en parties modulaires et modélisable
avec UML
- itératif et incrémental : projet découpé en itérations durant environs un mois
- gestion des besoin et des exigences : intégrer en priorité les besoins
supplémentaires du MOA
- production des composants : définir l’architecture à base de composants
- modélisation virtuelle : simplifie la réalité et donne une compréhension du
nouveau système
 - qualité : contrôler la fiabilité pour éviter l’augmentation exponentielle des coûts
- piloté par les risques : les mesures à prendre pour lever risques du projet sont à
identifier tôt.

2) Organisation
UP est organisé autour de quatre activités principales :
- initialisation (ou spécification) : définit la vision du projet, sa faisabilité
technico-financière
pour décider au mieux de sa poursuite ou pas
- analyse : construit une représentation idéale de la solution sans se fonder sur
les exigences et
les contraintes de conception
- conception : concevoir et mettre en application l’ensemble des éléments
opérationnels ; elle
permet de lever tous les risques identifiés
- implémentation : s’accompagne des tests et constitue la partie la plus
importante car donnant
solution aux utilisateurs

3) Variantes UP
Up prévoit globalement un cycle de vie où les itérations (spécifications, analyse,
conception, implémentation et tests) sont regroupées en catégories d’activités. Ces
activités sont soit initiales (création), soit intermédiaires (élaboration, construction)
soit finales (transition vers l’utilisateur ou mise en production)
- AUP : (Agile modeling PU) partie des préceptes UP permettant l’agilité du
développement, instanciation partielle de la méthode mettant l’accent sur
l’optimisation et l’efficacité sur terrain plus que sur le modèle théorique
- EUP : (Entreprise UP) est une instantiation intégrant les phases de post-
implantation et décrivant le cycle de vie du logiciel
- EssUP (Essential UP) de Ivar Jacobson, l’initiateur d’UML et RUP au travers sa
société Ivar Jacobson Consulting. EssUP est une extension de la méthode RUP qui
ajoute deux phases : production et retrait.
- Open UP insiste moins que RUP sur l’utilisation de la modélisation UML pour
les livrables du projet
 - RUP (Rationnal UP) processus de développement « clé en main » proposé et
commercialisé par Rational Software en 1998 pour compléter sa suite logicielle. Il est
modélisé et documenté avec UML
- XUP (eXtrême UP) est une instantiation hybride intégrant UP avec XP
(eXtreme Programming)
- 2TUP (Two Tracks Unified Process) qui est le plus récent, il a été proposé par
la société Valtech. C’est un processus unifié répondant aux contraintes de
changement continuel imposés par les systèmes d’informations. Partant du constat à
partir du quel 2TUP a été élaboré, toute évolution imposée au système d’information
peut se décomposer et se traiter parallèlement en suivant un axe fonctionnel et un
axe technique qui se fusionnent en un seul axe de réalisation.
 5. METHODOLOGIE (2 TUP)

Méthodes Agiles

• Les méthodes dites agiles décrivent des processus de développement

d’application basés sur la modélisation, la conception et la documentation
réalisés de façon efficace.
• Avec agile, on se focalise à livrer dans le temps au client final un programme
qui fonctionne et qui correspond à ses besoins. En se basant sur ce principe, la
plus part des équipes Agile considèrent que UML est souvent inutile et
qu’appliquer tous les principes d’XP sera plus efficace que de faire de l’UML
pour obtenir un logiciel fiable et facile à maintenir
• Les équipes Agiles se passent d’autant plus facilement d’UML que très souvent
elles ont remplacées les cas d’utilisation d’UML par quelques choses
d’équivalents que sont les Stories du Backlog

Les principales méthodes agiles sont :

• ASD (Adaptive Software Development) qui s’adresse tout particulièrement
aux projets d’é-business, les cinq principes qui guident ce modèle sont :
- Focalisation (viser les résultats à obtenir plutôt que les tâches)
- Itération : la conception se fait de façon itérative et incrémentale
- Échéances : le temps est découpé de manière à obtenir des
dates butoirs
- Gestion des risques (dans la mesure où le type de projet géré
répond à des contraintes de délais serrés
- Changement : capacité de supporter un changement fonctionnel ou
technique en cours de développement est un avantage concurrentiel.
Méthodes Agiles (ASD)
Le cycle de vie d’un projet ASD se déroule autour d’une série de cycles en trois
volets :
- Spéculation : initier le projet, déterminer la durée du projet, le
nombre d’itérations et les dates (4 à 8 semaines par itération),
 affecter un objectif (mission à chaque itération), dresser une liste
des tâches à réaliser
- Collaboration : livraison des composants, communication forte et
assez informelle
- Apprentissage : contrôle de qualité, suivi et bilan d’avancement,
communication forte et assez informelle,
Les caractéristiques principales du modèle ASD sont :
* focaliser sur l’objectif
* se baser sur des composants
* itérer
* découper le temps et fixer des deadlines
* piloter le projet par les risques
* accepter le changement
Asd nécessite d’être adaptée à chaque projet et, selon le contexte, d’être enrichie par
des caractéristiques d’autres méthodes « agiles »

Méthodes Agiles (Crystal)

La famille de ces méthodes a été mis en place par Alistair Cockburn.

Criticité Famille de méthodologies Crystal
Un défaut cause une
perte de :
Vie V6 V20 V40 V100 V200 V500 V1000

Revenu essentiel E6 E20 E40 E100 E200 E500 E1000

Argent A6 A20 A40 A100 A200 A500 A1000

Confort C6 C20 C40 C100 C200 C500 C1000

1-6 < 20 < 40 < 100 < 200 < 500 < 1000
Nombre de personnes à coordonner
Le principe de fonctionnement est de sélectionner la méthode en fonction de la criticité
du projet et du nombre de personnes à coordonner (un projet de 10 personnes ne peut
être géré comme celui de 100 personnes ou un projet de développement d’intranet
documentaire ou d’un système de sécurité). Crystal Clear désigne la famille de
méthodologie dédiées aux équipes d’un nombre des personnes inférieur à 8 personnes.

La succession des tâches se fait de la manière suivantes :

Les propriétés de Crystal sont :
• Livraisons fréquentes
• Aménagements permanents
• Communications osmotiques
• Confiances, liberté d’expression et sécurité personnelles
• Focus sur l’objectif et la disponibilité
• Contact permanent avec les utilisateurs
• Environnement de travail approprié pour l’automatisation des tests, la gestion
de configuration et les intégrations fréquentes
• Collaboration étroite entre toutes les parties prenantes y compris en dehors de
l’équipe
• Un réflexion constante sur ces propriétés

Méthodes Agiles (DSDM)

DSDM (Dynamic Software Development Method) crée en 1994, elle est le fruit du
travail d’un consortium de société désirant utiliser RAD de façon structurée et
indépendante en Grande-Bretagne.

Le principe de fonctionnement est basé sur une étroite collaboration entre les
utilisateurs et les équipes de développement. Les équipes doivent disposer d’un
pouvoir de décision de façon à pouvoir s’adapter aux besoins et aux délais, ce qui
permet de réaliser la livraison rapide des fonctionnalités demandées.
Le cycle de vie permet une gestion de projet très efficace et rapide.
La méthode DSDM ne préconise pas de règles de conduite strictes, mais doit être
adapté à chaque nouveau projet

Méthodes Agiles (FDD)

Le modèle FDD (Feature Driven Development) propose la mise en place d’itération

très courtes (deux semaines environ) avec, à chaque fois, la production d’un livrable
fonctionnel.
Ce modèle intéresse :
• Les développeurs (rapidité de trouver des livrables)
• Les chefs de projets (sécurisant, car l’état d’avancement est directement visible
au gré des itérations)
• Les clients (satisfait le client car concret, donnant une vision claire du planning
et des différentes étapes du projets)
Les caractéristiques de l’application constituent les principales bases de la méthode
FDD pour la conception et le développement. Le découpage applicatif en fonctions
élémentaires permet à la maîtrise d’ouvrage d’exprimer simplement ce qu’elle attend
et aux développeurs de mieux comprendre le domaine et la façon dont les choses sont
liées.

Méthodes Agiles (RAD)

• RAD (Rapid Application Development) n’est pas une méthode agile à

proprement parlé. Mais elle en est à l’origine. Car elle en est à l’origine.
• En fin 1980, James Martin présentait la première approche (sémi) itérative,
incrémentale préconisant un usage intensif des techniques de communication
facilitées. Jean-Pierre Vickoff a adapté le RAD au contexte français.

Méthodes Agiles (Scrum)

Scrum est conçu pour améliorer significativement la productivité des équipes de
développement généralement paralysées par des méthodologies lourdes.
Crée en 1996, ce modèle s’adapte à tout type de contexte et de projet, dès lors qu’un
groupe de personnes cherche à atteindre un but commun.
Scrum apporte beaucoup de souplesse et autorise des modifications lors de chaque
nouvelle itération de façon à livrer une solution la plus proche possible des besoins
comparativement aux méthodes classiques.
Cette méthode bien que flexible

CHAP II UP et UML

Suite à la complexité croissante des systèmes informatiques, les développeurs ont été
conduits à s’intéresser aux méthodes de modélisation, quoique ce phénomène ait plus
de 30 ans.
En 1994, il existait plus de 50 méthodes objets différentes, chacune ayant une notation
et un processus différents, mais convergents, en ce qui concerne la sémantique de leur
notation.
UML a ouvert un terrain d’unification en fusionnant les notations et en apportant la
précision et la rigueur nécessaires à la définition des concepts introduits.
L’introduction d’UML a apporté l’élan sans précédent à la technologie objet par la
proposition d’un standard de niveau industriel.
Cependant, il reste à définir le processus pour capitaliser les règles dans le domaine de
développement logiciel.

• Processus de développement logiciel

Un processus est une séquence d’étapes, en partie, ordonnées, qui concourent à
l’obtention d’un système logiciel ou à l’élaboration d’un système existant. Son objet
est de produire des logiciels de qualité répondant aux besoins de leurs utilisateurs dans
des temps et des coûts prévisibles. D’où un processus se décompose en deux axes :
* axe de développement technique (qui vise la qualité de
production)
* axe de gestion du développement ou axe fonctionnel (qui
mesure et prévoit les coûts et les délais)
UML traite les deux axes

• Processus unifié (UNIFIED PROCESS)

Un processus unifié est un processus de développement construit sur UML, il est
itératif, incrémental, centré sur l’architecture, conduit par les cas d’utilisation et piloté
par les risques.
Ce processus est organisé en 4 phases, à savoir : pré-étude (Inception), élaboration,
construction et transition. Ces activités de développement sont définies par 6
disciplines fondamentales qui décrivent la modélisation métier : la capture des besoins,
l’analyse et la conception, l’implémentation, le test et le développement
Le processus unifié est compris comme une trame commune des meilleures pratiques
de développement et non comme l’ultime tentative d’élaborer un processus universel.
Tout processus UP répond aux caractéristiques ci-après :
• Il est itératif et incrémental (la définition d’itération de réalisation est la
meilleure pratique de gestion des risques d’ordre à la fois technique et
fonctionnel.)
• Il est piloté par le risque (les causes majeures d’échec d’un projet logiciel
doivent être écartées en priorité. La première cause étant l’incapacité de
l’architecture technique à répondre aux contraintes opérationnelles et la
seconde est celle liée à l’inadéquation de développement aux besoins des
utilisateurs)
• Il est construit autour de la création et de la maintenance d’un modèle, plutôt
que de la production de plusieurs documents
• Il est orienté composant (garantie de souplesse pour le modèle et les logiciels
qu’il représente)
• Il est orienté utilisateur (la spécification et la conception sont construites à partir
des modes d’utilisation attendus par les acteurs su ystème).
• La méthode agile UP vient compléter la systémique des modèles ou
diagrammes UML. Elle est le résultat final d’une évolution de l’approche
d’Ericsson qui est au fondement d’une des premières méthodes de
développement pour l’application orientées objets (méthode Objectory
Processus (1987), Objectory Processus a servi de base à la société Rational pour
la création de Rational Objectory Process (1977), parente directe de RUP en
1998.
• UML couvre la plupart des étapes du cycle de vie d’un projet :

• La planification du projet comprend la définition du problème, l’établissement

d’un calendrier ainsi que la vérification de la faisabilité du projet
• L’analyse permet de préciser l’étendue des besoins auxquels doit répondre le
système puis de spécifier et de comprendre ce que doit faire ce système sans se
préoccuper de la réalisation
• La conception définit comment le système va être réalisé
• L’implémentation correspond à la réalisation du système dans un langage de
programmation
 • Les tests correspondent aux différentes vérifications consistant à s’assurer que
le système mis en place fonctionne conformément aux attentes
• Le déploiement consiste à appliquer sur le terrain d’attente le projet mis en
place et vérifier de manière à en récolter les fruits
• La maintenance qui consiste aux différentes adaptations aux nouveaux besoins
capturés après la mise en service du système.

UML découle de la fusion au sein de la société Rational Software des idées de James
Rumbaugh et Grady Booch auxquels s’est joint Ivar Jacobson.
UML s’est imposé comme le standard à utiliser en tant que langage de modélisation
objet.
Aujourd’hui, UML est appliqué depuis plus de quinze ans en enseignement et en
entreprise. Il est un langage visuel pour la modélisation :
* permettant la spécification, la visualisation, la construction et
la documentation des logiciels
* facilitant la communication et le travail en équipe
* ayant différents modèles pour différents points de vue
* utilisant une approche orienté objet
Ses objectifs sont la modélisation des systèmes par usage des techniques orientées
objets depuis l’analyse jusqu’à la maintenance et la création d’un langage abstrait
compréhensible par l’homme et interprétable par les machines

UML permet de construire plusieurs modèles d’un système. Certains du point de vue
de l’utilisateur, d’autres montrant la structure interne et d’autres donnant une vision
globale ou détaillée.
UML, dans sa phase 2, propose treize diagrammes dont 4 nouveaux introduits par
UML 2.0 qui peuvent être utilisés dans la description d’un système.
UML modélise le système suivant deux modes de représentation l’un concerne la
structure du système pris « au repos » (statique ou structurel), l’autre concerne sa
dynamique de fonctionnement.
Les deux sont nécessaires et complémentaires pour schématiser la façon dont est
composé le système et comment ses composants fonctionnent entre eux.

a) Diagrammes de structures ou diagrammes statiques

* diagramme de classes : donne la description statique du système en intégrant
dans chaque classe la partie dédiée aux données et celles consacrées aux traitements.
C’est le diagramme pivot de l’ensemble de la modélisation d’un système. Il est
généralement considéré comme le plus important dans un développement orienté
objet.
Il est prévu pour développer la structure des entités manipulées par les utilisateurs. En
conception, ce diagramme représente la structure d’un code orienté objet ou au mieux
les modules du langage de développement.

*le diagramme de cas d’utilisation : représente la structure des fonctionnalités

nécessaires aux utilisateurs du système. Il est utilisé dans les deux étapes de capture
des besoins fonctionnels et techniques. Il constitue le diagramme le plus structurant
dans l’analyse d’un système (certains auteurs placent ce diagramme parmi les
diagramme de comportement)
* le diagramme de package qui consiste à utiliser un diagramme de classe pour
y représenter la hiérarchie des modules d’un projet. Il donne une vue d’ensemble du
système structuré en package? Chaque package représente un ensemble homogène
d’éléments du système. C’est un diagramme de UML 2.
* le diagramme d’objet sert à illustrer des structures d‘instance de classes et des
liens entre instances. Il est utiliser, en analyse pour vérifier l’adéquation d’un
diagramme de classe à différents cas possibles.

* diagramme de composants représente les concepts connus de l’exploitant pour

installer et dépanner le système. Il représente les différents constituants du logiciel au
niveau de l’implémentation d’un système. Il s’agit de déterminer la structure des
composants d’exploitation que sont les librairies dynamiques, les instances de bases de
données, les applications, les progiciels, les objets distribués, les exécutables, etc.
* diagramme de structure composite décrit ma composition d’un objet
complexe lors de son exécution. C’est un diagramme de UML 2. il introduit la notion
de structure d’un objet complexe composé par des classes, par exemple, ou des objets
et des composants techniques. Il met l’accent sur les liens entre les sous-ensembles qui
collaborent.
* diagramme de déploiement décrit l’architecture technique d’un système avec
une vue centrée sur la répartition des composants dans la configuration d’exploitation.
Il correspond à la fois à la structure du réseau informatique qui prend en charge le
système logiciel et la façon dont les composants d’exploitation y sont installés.

b) Les diagrammes de comportement ou diagrammes dynamiques

* diagramme d’état-transitions, il montre les différents états des objets en
réaction aux événements. Il re présente le cycle de vie commun aux objets d’une même
classe. Il complète la connaissance des classes en analyse et en conception
* diagramme d’activité, il représente les règles d’enchainement des activités et
actions dans le système. Il permet d’une part de consolider la spécification d’un cas
d’utilisation. Il donne une vision des enchainements des activités propres à une
opération ou à un cas d’utilisation. Il représente les flots de contrôle et les flots de
données.
* diagramme de séquence, il permet de décrire les scenarios de chaque cas
d’utilisation en mettant l’accent sur la chronologie des opérations en interaction avec
les objets (à la suite du diagramme de communication).

* diagramme de communication, il est une représentation des scénarios des cas

d’utilisation qui met plus l’accent sur les objets et les messages échangés. Comme le
diagramme de séquence, ci-haut, il est un diagramme d’interaction UML. Il représente
les échanges de messages entre objets dans le cadre de fonctionnement particulier du
système.
* diagramme d’interaction, introduit en UML 2, il représente les règles
d’enchainement des activités et actions dans le système. Il permet d’une part de
consolider la spécification d’un cas d’utilisation. Il fournit une vue générale des
interactions décrites dans le diagramme de séquence et des flots de contrôle décrits
dans le diagramme d’activités. Il peut être utiliser en phase d’analyse qu’en phase de
conception pour la description d’une méthode complexe

* diagramme de temps, il est un formalisme UML 2. il provient de techniques connues

de l’ingénierie système et répond à des besoins de modélisation très spécifiques. Il
permet de représenter les états et les interactions d’objets dans un contexte où le temps
a une forte influence sur le comportement du système à gérer

La modélisation se construit par étapes successives de plus en plus détaillées (il est
impossible de produire un modèle représentant plusieurs milliers des lignes de code
sans passer par les étapes d’avancement qui permettent d’organiser le volume
d’information collectées).
Tout processus construit sur un modèle doit se doter d’une tactique d’avancement par
consolidation de chaque étape de construction du modèle.
Un tel avancement est itératif car il définit des objectifs à atteindre suivant un
découpage en niveaux de détail allant croissant par rapport au modèle de
développement.

• Capture des besoins fonctionnels :

Le niveau du contexte a pour objet de définir la frontière fonctionnelle entre le système
considéré comme une boîte noire et son environnement.
Le niveau des cas d’utilisation définit ensuite les activités attendues des différents
utilisateurs par rapport au système toujours envisagé comme une boîte noire.
Pour l’analyse :
On ouvre le système pour établir la structure des objets utilisés. Le modèle d’analyse
du domaine définit la structure et le comportement des objets connus dans le métier
des utilisateurs du système.

• Capture des besoins techniques

le modèle d’analyse technique établit des couches logicielles et y spécifie les activités
techniques attendues.
• Pour la conception générique
le modèle de conception système organise le système en composants qui en délivrant
les services techniques, assurent la réponse aux exigences opérationnelles du système.
• Pour la conception préliminaire
le modèle de conception système organise le système en composants, délivrant les
services techniques et fonctionnels.
Ce mode regroupe les informations des branches fonctionnels et techniques

• Pour la conception des classes

Le modèle de conception des composants fournit l’image « prêt à fabriquer » du
système complet.
Un modèle métier peut établir le contexte organisationnel dans lequel vient s’insérer le
système informatique
Ce modèle éventuellement objet constitue un point d’entrée possible au processus en
Y.
Une fois les objectifs établis, l’avancement sur un modèle se fait par itération des
mêmes tâches de construction jusqu’à l’obtention d’un modèle satisfaisant.

Les points de vue de modélisation

• Point de vue de spécification fonctionnelle (concerne l’organisation du modèle
des besoins fonctionnels exprimés par les utilisateurs et étudiés par les
analystes. Ces éléments correspondent aux cas d’utilisation organisés en
packages, aux acteurs, aux activités, aux interactions entre objets et aux
contraintes dynamiques)
• Point de vue structurel (touche à l’organisation du modèle des besoins élaboré
en classes par les analystes. Les éléments de construction y sont les catégories,
les classes, les associations, les généralisations, les attributs et les contraintes
structurelles)
• Point de vue matériel (le développement de la structure physique des machines
et des réseaux sur lequel repose le système informatique
Il concerne les ingénieurs système et réseaux. On compte les nœuds et connexions qui
permettent de prévoir le dimensionnement des processeurs et des bandes passantes)
• Point de vue de déploiement (représente la structure des postes de travail et
focalise les composants sur le réseau physique. Il concerne les ingénieurs
d’exploitation chargés d’installer le logiciel et d’identifier les causes de pannes.
Les éléments de construction y sont les postes de travail, les connexions et les
composants qui permettent d’étudier les échanges internes et externes du
système en développement.
• Point de vue d’exploitation (concerne l’organisation des composants et identifie
les fonctions prises en charge par logiciel installé. Il concerne à la fois les
ingénieurs d’exploitation (pour trouver le composant incriminé par une panne)
et les concepteurs (pour cartographier les dépendances logicielles). En
client/serveur, il est d’usage de répartir les composants suivants des
architectures 2-tiers et 3-tiers)
• Point de vue spécification logicielle (concerne les architectures qui décident de
repartir par couches les exigences techniques afin de les dissocier par nature de
responsabilité)
• Point de vue logique (concerne l’organisation du modèle de solution élaboré en
classes par les concepteur. Il concerne les éléments de construction y sont les
classes regroupées en catégories, les interfaces, les associations, les
généralisations, les réalisations, les attributs, les états, les opérations et leurs
méthodes. Ce points de vue est incontournables, car il fournit la vision « prêt à
coder » de la solution et inversement, documente le code produit).
CHAP III ANALYSE SOUS UP

III. 1. Introduction aux processus unifiés

La complexité toujours croissante des systèmes informatiques a conduit les
concepteurs à s’intéresser aux méthodes. En 1994, on a comptabilisé jusqu’à 50
méthodes objets différentes. Chacune se définissant par une notation et un processus
spécifique, mais la plupart convergent en ce qui concerne la sémantique de leur
notation. D’où, le travail de définition d’un processus est toujours resté vague et
succinct. UML a ouvert le terrain de l’unification en fusionnant les notations et en
apportant précision et rigueur à la définition des concepts introduits. UML a apporté
un élan sans précédent à la technologie objet, puisqu’elle y propose un standard de
niveau industriel. Il reste néanmoins à définir le processus pour réellement capitaliser
des règles dans le domaine du développement logiciel. Cette capitalisation ne se fait
pas par la définition d’un seul processus universel, ce qui serait une grave erreur. Les 3
amigos ont donc travaillé à unifier non pas les processus, mais plus exactement les
meilleures pratiques de développement orienté objet.

Processus de développement logiciel

Définition : Un processus est une succession d’étapes, en partie ordonnées, concourant
à l’obtention d’un système logiciel ou à l’évolution d’un système existant.
Objet : le processus de développement de logiciel est la production des logiciels de
qualité qui répondent aux besoins de leurs utilisateurs dans des temps et des coûts
prévisibles.
Axes de décomposition du processus :
- Axe de développement technique, qui se concentre sur la qualité de production
principalement
- Axe de gestion du développement, qui permet la mesure et la prévision des coûts et
des délais.

Processus unifié (UNIFIED PROCESS)

Un processus unifié est un processus de développement logiciel construit sur UML,
qui est itératif et incrémental (la définition d’itération est la meilleure pratique de
gestion des risques d’ordre à la fois technique et fonctionnel. Ce projet prend
généralement 9 mois pour son exécution tout en courant un risque majeur d’échec),
centré sur l’architecture, conduit par les cas d’utilisation (construit autour de la
création et de la maintenance, plutôt que de la production des beaucoup des
documents) et piloté par les risques (les causes majeures d’échecs d’un projet de
logiciel doivent être écartées en priorité. La première cause d’échec est l’incapacité de
l’architecture technique à répondre aux contraintes opérationnelles. Une deuxième
cause d’échec est celle liée à l’inadéquation du développement aux besoins des
utilisateurs).
Phases d’organisation d’un UP
La gestion d’un tel processus se fait en 4 phases qui sont la pré-étude, élaboration,
construction et transition.
UP doit être compris comme une trame commune des meilleures pratiques de
développement et non comme l’ultime tentative d’élaborer un processus universel

• Processus 2TUP (2 track Unified Process)

En plus des caractéristiques citées ci-dessus, 2TUP apporte une réponse aux
contraintes de changement continuel imposées aux systèmes d’information de
l’entreprise. En ce sens, il renforce le contrôle sur les capacités d’évolution et de
correction de tels systèmes.
« 2 track » signifie deux chemins. C’est un processus qui suit deux chemins
(fonctionnel et d’architecture technique qui correspondent aux deux axes de
changement imposés au système informatique).

Système Contraintes Techniques

Contraintes
D’information
fonctionnelles
D’entreprise

L’axiome fondateur de 2TUP consiste à constater que toute évolution imposée au

système d’information peut se développer et se traiter parallèlement suivant un axe
fonctionnel et un axe technique comme suit :
- L’axe de gauche (fonctionnelle) comporte la capture des besoins fonctionnels qui
produit un modèle des besoins focalisé sur le métier des utilisateurs. Il qualifie au plus
tôt le risque de produire un programme inadapté aux utilisateurs. Puis la maîtrise
d’œuvre consolide les spécifications et vérifie la cohérence et l’exhaustivité d’analyse,
qui consiste à étudier précisément la spécification fonctionnelle de manière à obtenir
une idée de ce que va réaliser le système en termes de métier.
Les résultats de l’analyse ne dépendent d’aucune technologie particulière.
Cette branche capitalise la connaissance du métier de l’entreprise et constitue un
investissement à MT et LT, car les fonctions du SI sont indépendantes des
technologies utilisées (évidence non respectée en pratique car la connaissance
fonctionnelle d’un produit se perd souvent dans la multitude des lignes de commande
de sa réalisation).

- L’axe de droite (architecture technique) comporte :

• la capture des besoins techniques qui recense toutes les contraintes et les choix
dimensionnement la conception du système. L’outil et les matériels sélectionnés
ainsi que la prise en compte de contraintes d’intégration avec l’existant
conditionnent généralement des prérequis d’architectures technique.
• La conception générique, qui définit les composants nécessaires à la
construction de l’architecture technique. Cette conception est la moins
dépendante possible des aspects fonctionnels. Elle a pour objectif d’uniformiser
et de réutiliser les mêmes mécanismes pour tout un système. L’architecture
technique construit le squelette du système informatique et écarter la plupart des
risques de niveau technique. L’importance de sa réussite est telle qu’il est
conseillé de réaliser un prototype pour assurer sa validité.
• L’axe de droite (architecture technique) capitalise un savoir faire technique et
constitue un investissement à CT et à MT car les techniques développées
peuvent être en effet indépendantes des fonctions à réaliser.
 • Actuellement l’architecture technique est de moins en moins la préoccupation
des services informatiques dont l’entreprise n’a pas vocation à produire du
code.

- L’axe du milieu comporte :

• La conception préliminaire, qui représente une étape délicates, car elle intègre
le modèle d’analyse dans l’architecture technique de manière à tracer la
cartographie des composants du système à développer.
• La conception détaillée, qui étudie ensuite comment réaliser chaque composants
• L’étape de codage, qui produit ces composants et teste au fur et en mesure les
unités de code réalisées
• L’étape de recette qui consiste à valider les fonctions du système développé.

Un processus itératif piloté par le les risques :

ITERATION : séquence distincte d’activités avec un plan de base et des critères
d’évaluation, qui produit une release (interne ou externe). l’itération fait allusion à une
amélioration ou une évolution du système, ce qui laisse entrevoir une évaluation par le
client
INCREMENT : c’est la différence entre releases produites à la fin de deux itérations
successives.
Le processus de développement en Y se reproduit à différents niveaux
d’avancement en se terminant sur la livraison d’une nouvelle release.