Cours Génie Logiciel (GL 2)

3 ème Année LMD

2017-2018 3 LMD Z.LAAREDJ

 Objectifs du module
Maîtriser les différentes méthodes de conception et de
développement d’un logiciel.

Mettre en relief la conduite d’un logiciel et les

différentes métriques de qualité d’un logiciel.

Comprendre les principes fondamentaux de l’approche

orientée objet.

Identifier les apports de la modélisation UML.

S’initier aux techniques de modélisation orientées

objet.
 Introduction
Dans la construction d’un système, un langage ne suffit
pas.

Équipe de
développement

Langage de
Modélisation Processus unifié
 Introduction

Les langages de modélisation permettant de visualiser, spécifier,

construire, documenter et communiquer les artefacts d'un système
étudié.

Un tel langage doit être utilisé dans le cadre d'un processus logiciel
complet.

L'objectif est d'obtenir une application logicielle robuste, résistante et

évolutive. Pour parvenir à ce but, il faut à la fois un processus et un
langage...
 Génie Logiciel
1.Motivations
Matériel et logiciel
Systèmes informatiques
- 80 % de logiciel;
- 20 % de matériel.

Depuis quelques années, la fabrication du matériel est assurée

par quelques fabricants seulement
- Le matériel est relativement fiable;
- Le marché est standardisé.

Les problèmes liés a l'informatique sont essentiellement des

problèmes de Logiciel.
 Génie Logiciel
1.Motivations
Spécificités du logiciel
Un produit immatériel, dont l'existence est indépendante du
support physique;

Un objet technique fortement contraint

- Fonctionne ou ne fonctionne pas;
- Structure complexe;
- Relève des modes de travail du domaine technique;

Un cycle de production différent

- La reproduction pose peu de problèmes, seule la première copie
d'un logiciel a un coût;
- Production a l'unité;
- Semblable au Génie Civil (ponts, routes...);
 Génie Logiciel
1.Motivations
Un processus de fabrication original
Le logiciel partage des propriétés contradictoires avec l'art, les
technologies et le Génie Civil;

Les possibilités de réutiliser les savoir-faire des autres technologies

sont (très) limitées;

Compte tenu du cycle de production, il faut bien faire tout de suite.

 Génie Logiciel
1.Motivations
La « Crise du logiciel »
Etude sur 8 380 projets (Standish Group, 1995)
- Succès : 16 %
- Problématique : 53 % (budget ou délais non respectes, défaut de
fonctionnalités)
- Echec : 31 % (abandonné)

Le taux de succès décroît avec la taille des projets et la taille des

entreprises
 Génie Logiciel
2. Le Génie Logiciel

Conférence de l'OTAN à Garmish, Allemagne (1968)

L'informatique ne répond pas aux attentes qu'elle suscite
L'informatique coûte très cher et désorganise les entreprises ou
Organisations

Introduction de l'expression « Génie Logiciel » (Software Engineering)

Comment faire des logiciels de qualité ?
Qu'attend-on d'un logiciel ? Quels sont les critères de qualité
pour un logiciel ?
 Génie Logiciel
2. Le Génie Logiciel

Qu’est ce que c’est logiciel?

Qualités attendues d’un logiciel ?
Qu’est-ce que le génie logiciel ?
Les grands principes du génie logiciel
Les processus de développement logiciel
 Génie Logiciel
2.1. Un Logiciel

Un logiciel est un ensemble de séquences d’instructions

interprétables par une machine et d’un jeu de données nécessaires à
ces opérations.

Le logiciel détermine donc les tâches qui peuvent être effectuées

par la machine, ordonne son fonctionnement et lui procure ainsi son
utilité fonctionnelle.

Programmes et la documentation associée – cahier de charges,

modèles…
 Génie Logiciel
2.1. Un Logiciel

Il peut interagir avec des clients, qui peuvent être :

Des opérateurs humains (utilisateurs, administrateurs, . . . ) ;
D’autres logiciels ;
Des contrôleurs matériels.

Il réalise une spécification : son comportement vérifie un ensemble de

critères qui régissent ses interactions avec son environnement.
 Génie Logiciel
2.2. Qualités attendues d’un logiciel

Comment fabriquer un logiciel de

qualité ?

En plus du respect (essentiel) de sa spécification, la

qualité d’un logiciel dépend d’autres critères
 Génie Logiciel
2.2. Qualités attendues d’un logiciel
Utilité
Adéquation entre
- Le besoin effectif de l'utilisateur
- Les fonctions offertes par le logiciel
Solutions :
- Emphase sur l'analyse des besoins
- Améliorer la communication (langage commun, démarche
participative)
- Travailler avec rigueur
 Génie Logiciel
2.2. Qualités attendues d’un logiciel
Utilisabilité
« Effectivité, efficacité et satisfaction avec laquelle des utilisateurs
spécifies accomplissent des objectifs spécifies dans un environnement
particulier ».

Facilité d'apprentissage : comprendre ce que l'on peut faire avec le

logiciel, et savoir comment le faire;
Facilité d'utilisation : importance de l'effort nécessaire pour utiliser
le logiciel à des fins données;
Solutions :
- Analyse du mode opératoire des utilisateurs
- Adapter l'ergonomie des logiciels aux utilisateurs
 Génie Logiciel
2.2. Qualités attendues d’un logiciel
Fiabilité
Correction, justesse, conformité : le logiciel est conforme à ses
spécifications, les résultats sont ceux attendus;
Robustesse, sureté : le logiciel fonctionne raisonnablement en
toutes circonstances, rien de catastrophique ne peut survenir, même
en dehors des conditions d'utilisation prévues ;
Mesures :
- MTBF : Mean Time Between Failures;
- Disponibilité (pourcentage du temps pendant lequel le système
est utilisable) et Taux d'erreur (nombre d'erreurs);
Solutions :
- Utiliser des méthodes formelles, des langages et des méthodes
de programmation de haut niveau;
- Vérifications, tests;
- Progiciels.
 Génie Logiciel
2.2. Qualités attendues d’un logiciel
Interopérabilité, couplabilité

Un logiciel doit pouvoir interagir avec d'autres logiciels;

Solutions :
- Bases de données (découplage données/traitements);
- « Externaliser » certaines fonctions en utilisant des « Middleware »
avec une API (Application Program Interface) bien définie;
- Standardisation des formats de fichiers (XML...) et des protocoles de
communication (CORBA...);
- Les ERP (Entreprise Resources Planning).
 Génie Logiciel
2.2. Qualités attendues d’un logiciel

Performance
Les logiciels doivent satisfaire aux contraintes de temps d'exécution
Solutions :
- Logiciels plus simples;
- Veiller a la complexité des algorithmes;
- Machines plus performantes.

Portabilité
Un même logiciel doit pouvoir fonctionner sur plusieurs machines;
Solutions :
- Rendre le logiciel indépendant de son environnement d'exécution;
- Machines virtuelles.
 Génie Logiciel
2.2. Qualités attendues d’un logiciel
Réutilisabilité
On peut espérer des gains considérables car dans la plupart des
logiciels :
- 80 % du code est du « tout venant » qu'on retrouve a peu prés
partout;
- 20 % du code est spécifique;
Solutions :
- Abstraction, généricité (ex : MCD générique de réservation);
- Construire un logiciel a partir de composants prêts a l'emploi.

Facilité de maintenance
Un logiciel ne s'use pas;
Pourtant, la maintenance prend une très grosse partie des efforts
de développement.
 Génie Logiciel
2.2. Qualités attendues d’un logiciel

Maintenance corrective
Corriger les erreurs : défauts d'utilité, d'utilisabilité, de fiabilité...
- Identifier la défaillance, le fonctionnement;
- Localiser la partie du code responsable;
- Corriger et estimer l'impact d'une modification.
Remarques
- La plupart des corrections introduisent de nouvelles erreurs;
- Les coûts de correction augmentent exponentiellement avec le
délai de détection;
- La maintenance corrective donne lieu a de nouvelles livraisons.
 Génie Logiciel
2.2. Qualités attendues d’un logiciel

Maintenance adaptative
Ajuster le logiciel pour qu'il continue a remplir son rôle compte
tenu du l‘évolution des :
- Environnements d'exécution;
- Fonctions à satisfaire;
- Conditions d'utilisation.
Ex : changement de SGBD, de machine…

Maintenance perfective, d'extension

Accroitre/améliorer les possibilités du logiciel ( les services offerts,
l'interface utilisateur, les performances...);
Donne lieu à de nouvelles versions.
 Génie Logiciel
2.2. Qualités attendues d’un logiciel
Facilité de maintenance
Objectifs
- Réduire la quantité de maintenance corrective;
- Rendre moins coûteuses les autres maintenances.
Enjeux
- Les coûts de maintenance se jouent très tôt dans le processus
d‘élaboration du logiciel;
- Au fur et a mesure de la dégradation de la structure, la
maintenance devient de plus en plus difficile.
Solutions :
- Réutilisabilité, modularité;
- Vérifier, tester;
- Structures de données complexes et algorithmes simples;
- Anticiper les changements a venir;
- Progiciels.
 Génie Logiciel
2.2. Qualités attendues d’un logiciel
Pour établir des méthodes fiables sur lesquelles construire une
industrie du logiciel. Il s’agit de se donner un cadre rigoureux pour :
Guider le développement du logiciel, de sa conception à sa
livraison.
Contrôler les coûts, et respecter les délais.
Établir des critères d’évaluation de la qualité d’un logiciel.
 Génie Logiciel
Le génie logiciel vise à garantir que :
La spécification répond aux besoins réels de ses clients ;
Le logiciel respecte sa spécification ;
Les coûts alloués pour sa réalisation sont respectés ;
Les délais de réalisation sont respectés.

Qu’est-ce que le Génie Logiciel ?

 Le Génie Logiciel
2.3. Qu’est-ce que le génie logiciel ?

Le génie logiciel est une activité d’équipe au sein d’un projet

Le génie logiciel est un domaine des sciences de l’ingénieur dont l’objet

d’étude est la conception, la fabrication, et la maintenance des systèmes
informatiques complexes.
 Le Génie Logiciel
2.4. Principes du génie logiciel
Un certain nombre de grands principes se retrouvent dans toutes
ces méthodes. La liste des grands principes proposé par Ghezzi :
La rigueur;
La décomposition des problèmes en sous-problèmes
indépendants;
La modularité;
L’abstraction;
L’anticipation des évolutions;
La généricité;
La construction incrémentale.
 Le Génie Logiciel
2.4. Principes du génie logiciel
Principe 1 : la rigueur
Les principales sources de défaillances d’un logiciel sont d’origine
humaine.
À tout moment, il faut se questionner sur la validité de son action.
Des outils de vérification accompagnant le développement
peuvent aider à réduire les erreurs. Cette famille d’outils s’appelle
CASE (Computer Aided Software Engineering).

Donc:
Les activités logicielles doivent être réalisées rigoureusement à travers :
Suivi de processus adaptés;
Utilisation correcte des techniques adaptés.
 Le Génie Logiciel
2.4. Principes du génie logiciel
Principe 2 : la décomposition en sous-problèmes

Dans le but de :
Décomposer les problèmes pour n’en traiter qu’un seul à la fois;
Simplifier les problèmes (temporairement) pour aborder leur
complexité progressivement.
 Le Génie Logiciel
2.4. Principes du génie logiciel
Principe 3 : la modularité
C’est une instance cruciale du principe de décomposition des
problèmes.

Il s’agit de partitionner le logiciel en modules qui :

ont une cohérence interne;
ils sont compréhensibles et indépendants
ils sont reliés entre eux

On recherche
Faible couplage
Forte cohésion
 Le Génie Logiciel
2.4. Principes du génie logiciel

Principe 4 : l’abstraction

C’est encore une instance du principe de décomposition des

problèmes.
Mécanisme qui permet de présenter un contexte en exprimant les
éléments pertinents et en omettant ceux qui ne le sont pas.
Il s’agit d’exhiber des concepts généraux regroupant un certain
nombre de cas particuliers et de raisonner sur ces concepts généraux
plutôt que sur chacun des cas particuliers.
Le fait de fixer la bonne granularité de détails permet :
de raisonner plus efficacement ;
de factoriser le travail en instanciant le raisonnement général
sur chaque cas particulier.
 Le Génie Logiciel
2.4. Principes du génie logiciel
Principe 5 : l’anticipation des évolutions

Un logiciel a un cycle de vie plus complexe que l’habituel cycle «

commande ! spécification ! production ! livraison »;
La maintenance est la gestion des évolutions du logiciel;
Il est primordial de prévoir les évolutions possibles d’un logiciel
pour que la maintenance soit la plus efficace possible;
Pour cela, il faut s’assurer que les modifications à effectuer soient le
plus locales possibles;
Ces modifications ne devraient pas être intrusives car les
modifications du produit existant remettent en cause ses précédentes
validations;
Concevoir un système suffisamment riche pour que l’on puisse le
modifier incrémentalement est l’idéal.
 Le Génie Logiciel
2.4. Principes du génie logiciel
Principe 6 : la généricité

Un logiciel réutilisable a beaucoup plus de valeur qu’un composant

dédié;
Un composant est générique lorsqu’il est adaptable.

Principe 7 : la construction incrémentale

Un développement logiciel a plus de chances d’aboutir si il suit une

cheminement incrémental.
 Le processus de développement logiciel
Qu’est ce qu’un processus ?
Un processus est une série de tâches qui fournissent un ou plusieurs
délivrables.

Un processus définit qui fait quoi, quand et comment pour atteindre

un objectif donné.

Un processus de développement logiciel est un ensemble (structuré)

d’activités que conduisent à la production d’un logiciel.

Processus d’ingénierie !" #$

logicielle
 Le processus de développement logiciel

A quoi sert un processus logiciel ?

Un processus logiciel fournit une approche pour assigner des tâches

et des responsabilités à l’intérieur d’une organisation.

Un processus permet la production d’un logiciel de haute qualité avec

un temps et un budget limité.
Les objectifs d’un processus de développement
logiciel ?
L’objectif d’un processus est de produire un logiciel de
haute qualité en respectant des contraintes de délai, de coûts et
de performance

Fournit les lignes directrices pour un développement efficace

d’un logiciel de qualité;
Réduit les risques et améliore les prévisions;
Décrit les meilleures méthodes de travail pour :
Apprendre des expériences précédentes;
L’amélioration du support de formation;

Établit une vision et une culture commune.

Les objectifs d’un processus de développement
logiciel ?

Facilite la mise en œuvre : grâce aux six meilleures pratiques de

Rational, le processus est facile à mettre en œuvre.

Dicte au développeur comment implémenter en utilisant les outils

standards de développement.
 Maturité du processus de développement
logiciel
Le Modèle de Maturité (CMM) du SEI
Initial
Reproductible
Défini
Maitrisé
Optimisé

Pour maîtriser le processus de développement logiciel et assurer la

qualité du logiciel, il faut :
Séparer le développement en plusieurs étapes
Organiser ces étapes et modéliser le processus de
développement
Contrôler le processus de développement
 Maturité du processus de développement
logiciel
Niveau de maturité 1 : Initial

Chaotique : plans et contrôles inefficaces

Processus essentiellement non contrôlé, non défini;
Le succès dépend des individus.

Niveau de maturité 2 : Reproductible

Intuitif : dépend encore des individus

Procédures de gestion utilisées, gestion des configurations
et assurance qualité;
Pas de modèle formel de processus.
 Maturité du processus de développement
logiciel
Niveau de maturité 3 : Défini
Qualitatif : institutionnalise
Procédures formelles pour vérifier que le processus est
utilise

Niveau de maturité 4 : Maîtrisé

Quantitatif : Processus de mesures
Gestion quantitative de la qualité

Niveau de maturité 5 : Optimisé

Améliorations retournées dans le processus
Stratégies d'amélioration du processus
 Cycle de vie d’un logiciel

Pour obtenir un logiciel de qualité, il faut maîtriser le processus

d‘élaboration
La vie d'un logiciel est composée de différentes étapes;
La succession de ces étapes forme le cycle de vie du logiciel;
Il faut contrôler la succession de ces différentes étapes.

C’est quoi un cycle de vie d’un

logiciel ?
 Cycle de vie d’un logiciel
Définition
Le cycle de vie d'un logiciel (software lifecycle) désigne l’ensemble
des étapes nécessaires au bon développement d’un logiciel.
Le cycle de développement décrit les enchaînements prévus des
différentes phases.
Chaque phase ou étape produit en général des documents qui
vont servir à une autre phase ultérieure.
Un bon développement logiciel doit reposer sur une méthode et
un cycle de développement bien précis.
 Cycle de vie d’un logiciel

%& # '

Définir des jalons

intermédiaires pour Détecter les erreurs
la validation du Vérifier le processus
au plus tôt afin de
développement de développement
minimiser le coût et
logiciel, autrement en termes
les délais de
dit, vérifier la d’adéquation des
réalisation ainsi
conformité du méthodes mises en
maîtriser la qualité
logiciel avec les œuvre
du logiciel.
besoins exprimés
 Les étapes d’un cycle de vie d’un logiciel

Etude de faisabilité
Déterminer si le développement est faisable, compte tenu de
attentes et de la difficulté de développement.
Etude de marché : déterminer s'il existe un marché potentiel pour
le produit.
 Les étapes d’un cycle de vie d’un logiciel

Spécification
Déterminer les fonctionnalités que doit posséder le logiciel et
leurs contraintes
Collecte des exigences : obtenir de l'utilisateur ses exigences
pour le logiciel;
Analyse du domaine : déterminer les tâches et les structures
qui se répètent dans le problème.
Les étapes d’un cycle de vie d’un logiciel

Pouvez-vous sauter l'étape de spécification ?

Non

Pourquoi ?
Les étapes d’un cycle de vie d’un logiciel

• L’étape de spécification force à comprendre ce que doit faire

chaque composant
• La spécification permet d’énoncer des propriétés sur le système
avant même son développement.

• La validation consiste à se demander si le texte formel « dit

bien » ce que l'on veut qu'il dise, s'il « traduit » bien la demande
informelle faite par celui qui commande le logiciel
• La validation ne peut pas être automatisée
• La spécification permet de poser les bonnes questions afin de
s’assurer de l’adéquation des composants au cahier des charges
Les étapes d’un cycle de vie d’un logiciel

• Une spécification est un contrat que le programmeur doit

respecter
• La spécification est une référence pour la suite du
développement

• Une spécification permet à chaque étape du développement de

vérifier que la réalisation du système respecte les attentes
initiales.
• En conception : Cet algorithme calcule-t-il bien ce que j’ai
spécifié ?
• En intégration : Ce programme réalise-t-il bien le composant
initialement spécifié
 Les étapes d’un cycle de vie d’un logiciel

! "

La spécification d’un logiciel peut prendre de nombreuses formes.

La complexité et les dimensions de la spécification peuvent varier

énormément en fonction de l’environnement d’utilisation du logiciel et
des objectifs auxquels il répond.
Les étapes d’un cycle de vie d’un logiciel

Les formes de spécification

Approches Approches semi- Approches

informelles formelles formelles
 Les étapes d’un cycle de vie d’un logiciel
Approches
informelles

Langage naturel structuré: des modèles de fiches, et

des formulations, dont le sens est explicité et moins
ambiguë.

Description algorithmique: un langage de

programmation abstrait est utilisé pour donner une
vision opérationnelle du système.
 Les étapes d’un cycle de vie d’un logiciel
Approches
informelles

Notation graphique: des diagrammes annotâtés

généralement par du texte en langage structuré,
représentent le système.

Spécification mathématique: des formules ou des

objets mathématiques définissent un système en
s’appuyant sur des théories dont les axiomes sont
explicités.
 Les étapes d’un cycle de vie d’un logiciel
Approches semi-
formelles

Elles visent à introduire un langage normalisé pour

décrire le logiciel et sa spécification.
La sémantique du langage de spécification n’est
pas formalisée.
Précisent le discours du concepteur si on le
compare à celui décrit à l’aide du langage naturel,
elles contiennent certaines ambiguïtés et n’offrent
aucune garantie sur la qualité des résultats.
 Les étapes d’un cycle de vie d’un logiciel
Approches semi-
formelles

Méthodes : Rationale Unified Process, . . .

Outils et notations : UML, . . .
Ces méthodes sont utilisées aujourd’hui par l’industrie
du logiciel.
 Les étapes d’un cycle de vie d’un logiciel

Approches
formelles

Utilisent des outils mathématiques et des méthodes de

preuve pour construire un logiciel correct par
construction dont la vérification est automatisée ou
assistée.

Méthodes : méthode B, model-checking, logique de

Hoare, . . .
Outils et notations : Coq, Z, Frama-C, . . .
 Les étapes d’un cycle de vie d’un logiciel
Approches
formelles

Ces méthodes sont utilisées pour développer des

logiciels critiques.
Elles correspondent au niveau le plus élevé de
certification.
Exemple : la méthode B est appliquée pour développer
le logiciel embarqué des lignes de métro 14 (1998) et 1
à Paris.
 Les étapes d’un cycle de vie d’un logiciel

Organisation du projet
Déterminer comment on va développer le logiciel
Analyse des coûts : établir une estimation du prix du projet;
Planification : établir un calendrier de développement;
Assurance qualité du logiciel : déterminer les actions qui
permettront de s'assurer de la qualité du produit fini;
Répartition des tâches : hiérarchiser les tâches et sous-tâches
nécessaires au développement du logiciel.
 Les étapes d’un cycle de vie d’un logiciel
Conception
Activité destinée à produire une solution à un problème
Déterminer la façon dont le logiciel fournit les différentes
fonctionnalités recherchées
Conception générale
Conception architecturale : déterminer la structure du
système;
Conception des interfaces : déterminer la façon dont les
différentes parties du système agissent entre elles.
Conception détaillée : déterminer les algorithmes pour les
différentes parties du système.
 Les étapes d’un cycle de vie d’un logiciel

Implémentation (Codage)
Activité plus traditionnelle de programmation ou
d’implémentation du résultat de la conception dans un langage
exécutable (ou plusieurs langages).
Il s’agit du codage dans un langage de programmation, càd de la
traduction des structures de données et des algorithmes définis dans
la phase de conception.
 Les étapes d’un cycle de vie d’un logiciel
Tests
Essayer le logiciel sur des données d'exemple pour s'assurer qu'il
fonctionne correctement
Tests unitaires : faire tester les parties du logiciel par leurs
développeurs;
Tests d'intégration : tester pendant l'intégration;
Tests de validation : pour acceptation par l'acheteur;
Tests système : tester dans un environnement proche de
l'environnement de production;
Tests Alpha : faire tester par le client sur le site de
développement;
Tests Bêta : faire tester par le client sur le site de production;
Tests de régression : enregistrer les résultats des tests et les
comparer a ceux des anciennes versions pour vérifier si la
nouvelle n'en a pas dégrade d'autres.
 Les étapes d’un cycle de vie d’un logiciel
Livraison
Fournir au client une solution logicielle qui fonctionne
correctement
Installation : rendre le logiciel opérationnel sur le site du
client;
Formation : enseigner aux utilisateurs a se servir du logiciel;
Assistance : répondre aux questions des utilisateurs.
 Les étapes d’un cycle de vie d’un logiciel
Maintenance
Comprenant toutes les actions correctives (maintenance
corrective) et évolutives (maintenance évolutive) sur le logiciel;
Mettre a jour et améliorer le logiciel pour assurer sa productivité;
Pour limiter le temps et les coûts de maintenance, il faut porter
ses efforts sur les étapes antérieures.
 Documents produits dans le cycle de vie
Documents produits
Cahier des charges
Est le document le plus important puisqu’il est la référence
obligée de tout le développement;
Il contient le contexte, les besoins du client et leurs
évolutions, en décrivant les fonctionnalités désirées;
Définit les clauses techniques, les clauses de qualité et les
clauses administratives applicables à la fourniture recherchée;
Ecrit en langage informel.
 Documents produits dans le cycle de vie
Documents produits

Un modèle de cahier de charges

Positionnement et objectifs : dans quel contexte le cahier de

charges est-il établi et quels sont ses objectifs
Spécifications applicatives ou fonctionnelles : descriptions des
données, traitements, présentations, interfaces.
Spécifications techniques : informations plus spécifiques sur le
contexte.
Spécifications administratives : budget, délais, propriété, clauses
légales.
Spécifications d’évaluation : les éléments qui permettront de
valider l’offre faite par le futur contractant.
Contraintes de réalisation.
 Documents produits dans le cycle de vie
Documents produits
Spécifications
Décrit précisément les conditions que doit remplir le logiciel
Modèle objet : indique les classes et les documents principaux;
Scenarios des cas d'utilisation : indique les différents
enchaînements possibles du point de vue de l'utilisateur.
 Documents produits dans le cycle de vie
Documents produits
Calendrier du projet
Ordre des différentes taches;
Détails et ressources qu'elles demandent.

Plan de test du logiciel

Décrit les procédures de tests appliquées au logiciel pour
contrôler son bon fonctionnement.
Tests de validation : tests choisis par le client pour
déterminer s'il peut accepter le logiciel.
 Documents produits dans le cycle de vie
Documents produits
Plan d'assurance qualité
Décrit les activités mises en ouvre pour garantir la qualité du
logiciel
Manuel utilisateur
Mode d'emploi pour le logiciel dans sa version finale
Code source
Code complet du produit fini
Rapport des tests
Décrit les tests effectués et les réactions du système
Rapport des défauts
Décrit les comportements du système qui n'ont pas satisfait le
client
Il s'agit le plus souvent de défaillances du logiciel ou d'erreurs
 Documents produits dans le cycle de vie
# ! $% !
# # ' ( ) # #
* )# +# # * )#
, -. - / # , ' #
* - ) # #
* + - + 0 % #
, - # # !) ' #
# # ) !) ' #
* )# - # * )#
# # - 1# , ' #
* - - ) & # , ' #
)) # - # # 2 #
# # ( ) # #
 Modèles de cycle de vie d’un logiciel
Le modèle en cascade
 Modèles de cycle de vie d’un logiciel
Le modèle en cascade

Hérité des méthodes classiques d’ingénierie. Il s’adapte donc bien

dans un contexte où le logiciel fait partie d’un système complexe
englobant.
Chaque phase doit se terminer pour commencer la suivante.
Des documents sont produits pour concrétiser la réalisation de
chaque phase.
La production de documents entre chaque phase améliore le suivi
du projet.
Impose une importante réflexion sur les choix faits car le coût de
la correction d’une erreur est important.
Adapte pour des projets de petite taille, et dont le domaine est
bien maitrisé.
 Modèles de cycle de vie d’un logiciel
Le modèle en cascade

Problèmes
Il est difficile de séparer les étapes
On peut l’utiliser quand les besoins sont bien définis et ils sont
stables.
Avantages
Bien documenté à chaque phase
Inconvénients
Rigide (on ne peut pas de répondre au besoins nouveaux ou
modifiés des clients)
 Modèles de cycle de vie d’un logiciel
Le modèle en V
 Modèles de cycle de vie d’un logiciel
Le modèle en V
Avantages
Plus réactif que le modèle en cascade
Forte structuration des étapes de test
Inconvénients
Hypothèse de stricte séparation entre implantation et
spécification
Logiciel délivré seulement à la fin du projet
 Modèles de cycle de vie d’un logiciel
Le modèle en incrémental
 Modèles de cycle de vie d’un logiciel
Le modèle incrémental

Concevoir et livrer au client un sous-ensemble minimal et

fonctionnel du système autrement dit, le produit est délivré en
plusieurs fois, de manière incrémentale, c’est à dire en le complétant
au fur et à mesure et en profitant de l’expérimentation
opérationnelle des incréments précédents.
Procéder par ajouts d'incrèments minimaux jusqu'a la fin du
processus de développement
Avantages : meilleure intégration du client dans la boucle, produit
conforme a ses attentes
 Modèles de cycle de vie d’un logiciel
Le modèle en Spirale
 Modèles de cycle de vie d’un logiciel

Le modèle en Spirale

Un modèle mixte
A chaque cycle, recommencer : Consultation du client, Analyse des
risques, Conception, Implémentation, Tests, Planification du prochain
cycle
 Modèles de cycle de vie d’un logiciel
Le modèle en Spirale
Avantages
Combine les avantages des modèles en cascade /V;
Tient compte de la nature itérative d’un projet;
Une plus grande attention sur la réutilisabilité;
Meilleure élimination des erreurs;
Objectifs de qualité pris en compte et intégré;
Maintenance et développement dans un même contexte.
Inconvénients
Difficile à comprendre sans être expert technique;
Nécessite capacité à bien analyser les risques;
Nécessite gestionnaires compétents.
 Modèles de cycle de vie d’un logiciel
Le modèle évolutif

Spécification Version initiale

Versions
Aperçu de Développement intermédiaires
description

Versions
Validation finale
 Modèles de cycle de vie d’un logiciel
Le modèle évolutif

Les trois activités (spécification, développement, validation) sont

entrelacées;
Un prototype est écrit rapidement et est confronté à l’utilisateur;
En fonction du résultat, on raffine la spécification;
On reprend le prototype ou on le réécrit jusqu’à l’obtention du
système final.
 Modèles de cycle de vie d’un logiciel
Le modèle évolutif
Caractéristiques

Augmente les chances de répondre aux besoins de l’utilisateur

car il permet de les comprendre plus rapidement.

Remplit le critère d’incrémentalité.

Ne dispense d’écrire la spécification du système car il faut

s’assurer que l’implémentation est correct.

 Modèles de cycle de vie d’un logiciel
Le modèle évolutif
Problèmes
Manque de visibilité c’est-à-dire, la visibilité de l’avancement
du développement est peu clair. Ce qui rendre la gestion d’un
projet en utilisant ce modèle difficile.
Mauvaise structure autrement dit, il est plus difficile de
structurer correctement le logiciel, car les prototypes sont par
définition des produits “bricolés”.
Exige des qualités spéciales des programmeurs
Le coût en termes de tests et de validation du produit final
peuvent être très importants.
 Modèles de cycle de vie d’un logiciel
Le modèle évolutif
Application
Systèmes de petite et moyenne taille
Parties de grands systèmes
Systèmes de courte vie.
 Modèles de cycle de vie d’un logiciel
Le prototypage
Prototype : version d'essai du logiciel
Pour tester les différents concepts et exigences
Pour montrer aux clients les fonctions que l'on veut mettre en
œuvre
Lorsque le client a donné son accord, le développement suit
souvent un cycle de vie linéaire
Avantages : Les efforts consacrés au développement d'un
prototype sont le plus souvent compensés par ceux gagnés à ne pas
développer de fonctions inutiles.
 Modèles de cycle de vie d’un logiciel
Le modèle par composants
 Modèles de cycle de vie d’un logiciel
Le modèle par composants
Caractéristiques
Vise à développer un logiciel en grande partie à l’aide d’une
base de composants génériques pré-existants.
L’élaboration de la spécification est dirigée par cette base : une
fonctionnalité est proposée à l’utilisateur en fonction de sa
facilité à l’obtenir à l’aide d’un composant existant.
Obtenir rapidement des produits de bonne qualité puisqu’ils
sont construits à partir de composants qui ont fait leur preuve.
Le travail d’intégration peut s’appuyer sur des outils dirigés par
des descriptions de haut niveau du système.
 Modèles de cycle de vie d’un logiciel
Le modèle par composants

Inconvénients
Le principal défaut de ce modèle est de ne pas construire un
produit adapté aux besoins du client.
Un travail complexe de configuration et d’adaptation peut être
nécessaire.
 Modèles de cycle de vie d’un logiciel
En réalité
Il n’y a pas de modèle idéal car tout dépend des circonstances
Le modèle incrémental est risqué car il ne donne pas beaucoup
de visibilité sur le processus complet.
Souvent, un même projet peut mêler différentes approches,
exemple :
spirale pour les sous-systèmes à haut risque ;
cascade pour les sous systèmes bien connus et à faible risque.
 Méthodes de développement logiciels

Il existe différents méthodes de développement logiciels qui

organisent de façon différentes les activités de cycle de vie

d’un logiciel.
 UP ( Unified Process)
Définition du processus unifié

Un processus de développement logiciel, c’est-à-dire qu’il

regroupe les activités à mener pour transformer les besoins d’un
utilisateur en système logiciel (Jacobson, Booch, Rumbaugh 1999).
UP est itératif, centré sur l'architecture, Piloté par des cas d'utilisation et
orienté vers la diminution des risques.

Une méthode de développement pour les logiciels orientés

objets vient pour compléter la systémique des modèles UML.

C'est un patron de processus pouvant être adaptée à une large

classe de systèmes logiciels, à différents domaines d'application, à
différents types d'entreprises, à différents niveaux de compétences et à
différentes tailles de l'entreprise.
 UP (Unified Process)

Les caractéristiques du processus unifié

1. UP est itératif et incrémental

Le projet est découpé en itérations ou étapes de courte durée
qui permettent de mieux suivre l’avancement globale.
A la fin de chaque itération une partie exécutable du système
finale est produite, de façon incrémentale (par ajout).
 UP (Unified Process)
Les caractéristiques du processus unifié

2. UP est centré sur l'architecture

Tout système complexe doit être décomposé en partie modulaire
afin d’en faciliter la maintenance et l’évolution. Cette architecture
(fonctionnelle, logique, matérielle, etc.) doit être modéliser en UML.
 UP (Unified Process)

Les caractéristiques du processus unifié

3. UP est guidé par les cas d'utilisation d'UML

Le but principal d’un système d’informatique est de satisfaire les
besoin de client. Ce qui inclut l’utilisateur dans le processus de
développement.
Le cas d’utilisation permettent d’illustrer ces besoins. Ils
détectent puis décrivent les besoin fonctionnel et leur ensemble
constitue le modèle de cas d’utilisation qui montre les fonctionnalités
complètes du système.
 UP (Unified Process)

Les caractéristiques du processus unifié

4. UP est piloté par les risques

Les risques majeurs du projet doivent être identifiés au plus tôt
mais surtout levés le plus rapidement. Les mesures à prendre dans ce
cadre déterminent l’ordre des itérations.
 La méthode RUP
Qu’est ce que « RUP » ?

&'$

Rational Unified Process

Dérivée de UP (UP a été créée en 1996)
Commercialisée par IBM en 1998

( !% !

Itérative
Incrémentale
Pilotée par les cas d’utilisation
Centrée sur l’architecture et la réduction des risques
Produit de qualité
 Un bref historique du RUP
Le RUP est une instance spécifique et très détaillée d'un processus plus
générique décrit par Ivar Jacobson, Grady Booch et James Rumbaugh
dans le manuel pédagogique The Unified Software Development
Process.
La méthode RUP (Concept et vocabulaire)
) !

3* ) # # # ) % # -. % - )
5 3 # 4

3 6) # # -. # #
# # 37
3
# # )
# *
# 8#
#
# )

39 # -. ' # :) - # # -. # # -
# ' # 3
- ))
# 4
# ; -$ : <

3 + # -. # #
) 3 # 4 -
La méthode RUP (Concept et vocabulaire)

Rôle
Activité

Analyste
Cas d’utilisation -. # #

Responsable de
Artéfact

paquetage des
Cas d’utilisation
cas d’utilisation
 La méthode RUP (Concept et vocabulaire)
&* $ ! # &

Ressource Rôle Activités

Paul Concepteur Définir Opérations

Rédacteur. Détailler le D. Utilisation
Marie
D.Utilisation Trouver Acteurs et Cas Util.
Joseph
Analyste Système Réaliser les tests des unités.
Sylvia
Développeur. Concevoir.
Stefanie Architecte

Chaque individu est

associé
à un ou plusieurs rôles.
 Principes de RUP

Pilotée par les cas d’utilisation

Construction d’un système à base de composants

Adaptable aux changements

Gestion des risques

Livraison de qualité

Concentrée sur le code exécutable

Travail en équipe
 Principes de RUP
Le processus Unifié Rational décrit comment appliquer les
six directives de l’ingénierie logicielle

Utiliser le Développement Itératif

(Ré)Utiliser Modeler Contrôler

Analyser Composants Visuellement
(UML) la Qualité
les Besoins Architectures

Contrôler le
Changement
 Principes de RUP

Les six meilleures pratiques fournissent les bases pour le Processus

Unifié de Rational.

Cependant, cette application nécessite des instructions étapes par

étapes.

Ces instructions sont fournies dans le Processus Unifié de Rational,

qui comprend toutes les activités devant être appliquées pour
construire un logiciel.
 Les deux visions du RUP
L’architecture bidirectionnelle: RUP gère le processus de
développement par deux axes.

L'axe vertical : représente les principaux enchaînements

d'activités, qui regroupent les activités selon leur nature. Cette
dimension exprime l'aspect statique du processus termes de
composants, de processus, d'activités, d'enchaînements, d'artefacts
et de travailleurs.

L'axe horizontal : représente le temps et montre le déroulement

du cycle de vie du processus; cette dimension exprime l'aspect
dynamique du processus en terme de cycles, de phases, d'itérations
et de jalons.
Les deux visions du RUP
 Cycle de vie du RUP
L'objectif d'un processus unifié est de maîtriser la complexité des
projets informatiques en diminuant les risques. Cela est fait en
appliquant 4 phases.

+ ! ,# -
! .

/ 0 !

! !

1 !
 Cycle de vie du RUP

+ !

Définit le champ d’action du projet

Durant l’étude d’opportunité (démarrage), les objectifs du projet
sont définis.

En identifiant tous les acteurs et les cas d’utilisation, et en

dessinant les cas d’utilisation essentiels (20% du modèle).

Un plan de gestion de projet est fait pour déterminer les

ressources nécessaires pour le projet.
 Cycle de vie du RUP

/ 0 !

Durant l’élaboration, il faut concentrer sur deux choses :

Avoir une bonne connaissance des besoins (exigences très

avancées (90%)) et ;

Etablir une base de l’architecture.

Possibilité d’éliminer beaucoup de risques;

Avoir une bonne idée de ce qui doit être fait, et

Une bonne estimation des ressources et des coûts;

Programmation largement engagée.
 Cycle de vie du RUP

! !

Durant la Construction, on développe le produit en plusieurs itérations

pour une version bêta (développement de toutes les fonctionnalités, doc
incluse) .

1 !

Durant la Transition, on prépare le produit pour l’utilisateur final et la

formation, l’installation, le support, autrement dit déployer dans
l’environnement opérationnel.
RUP : Processus agile ou lourd?

2
Ou se situe RUP ?
 Les avantages de RUP
Traçabilité à partir des Uses Cases jusqu’au déploiement grâce à
l’utilisation de l’UML,
Approche basée sur l’architecture
Gestion des risques dans les projets, autrement dit les risques sont
atténués dés le début du projet car la planification est complète et
détaillé,
Cadre propice à la réutilisation,
Le changement est mieux géré, car il est possible de recadrer le
projet après une itération.
Vérification constante de la qualité
 Les inconvénients de RUP

Coût de personnalisation souvent élevé

Très axé processus

Vision non évidente ni immédiate

Management lourd à mettre en place

 La méthode XP

3$

eXtreme Programming
Une méthode de développement agile, orientée projet
informatique et dont les ressources sont régulièrement
actualisées.
Destinée à accélérer la réalisation des projets de type
flexible.

$ 0

Participation du client au développement

La méthode XP
=>
!
!
4 0 5
 Valeurs XP

Développement = Effort collectif de création

Avoir une vision commune et pouvoir se synchroniser
Qualité de la communication
Communication directe et le contact humain
Faiblesse pour la traçabilité et la structuration
Augmentation de la réactivité
Communication écrite présente, en général par du code
 Valeurs XP

« La chose la plus simple qui puisse marcher »

Eviter la complexité inutile dans le code
Toute duplication doit être éliminée
 Valeurs XP

& ! 6 ! ,4 0 5.

Boucles de feedback pour réduire les risques

Connaître l’état du projet

Rectifier le tir si nécessaire

Facteur de qualité

Acquisition d’expérience

Amélioration constante du travail

 Valeurs XP

Se lancer dans un projet non entièrement spécifié;

Accepter de remanier une portion de code devenue complexe;

Appliquer les valeurs de feedback et de communication;

Accepter de montrer ses propres limites

Maintenir une transparence complète

 La méthode XP
Caractéristiques
Rapidité de développement par cycle
Déterminer les besoins clients;
Transformer les besoins en fonctions à réaliser et en tests
fonctionnels;
Chaque développeur s'attribue avec un binôme des tâches;
Lorsque les tests sont concluants, l’application est livrée,
Le cycle se répète tant que le client peut fournir des besoins.
Réactivité aux changements
Qualité du code et des tests
Travail en équipe
Cycle de vie de XP
 Pratiques XP
, #
• Développement piloté par les tests
• Conception simple
• Remaniement

* % #
• Programmation en binôme
• Responsabilité collective du code
• Règles de codage
• Intégration continue

? # - ) & #
• Client sur site
• Rythme durable
• Livraisons fréquentes
• Planification itérative
Principaux facteurs de succès de XP

Quelques développeurs expérimentés... et ouverts

Une équipe capable de travailler... en équipe
Principaux facteurs de succès de XP

8 !

Environnement de travail adapté (« War Room »)

Hiérarchie consentante
Culture d’entreprise adaptée
Pas de mérite basé sur les heures supplémentaires
Pas de jeu politique (gagnant-gagnant)
Pas d’attachement aux méthodes linéaires
 Principaux facteurs de succès de XP

1 % 9

Possibilité de travailler sur des portions réduites de

l’application
Valable dans le cas d’une reprise d’un gros projet
Redécouper le logiciel dans un tel cas
Langage de programmation permettant des
mécanismes d’abstraction et de factorisation
La plupart des langages objets entrent dans cette
catégorie
Disposer d’un outil de gestion de versions efficace
 Les points forts de la méthode XP

Itératif

Simple à mettre en œuvre

Fait une large place aux aspects techniques : prototypes, règles de

développement, tests…

Innovant: programmation en duo…

 Les points faibles de la méthode XP

Ne couvre pas les phases en amont et en aval au développement :

capture des besoins, support, maintenance, tests d'intégration…;
Élude la phase d'analyse, si bien qu'on peut dépenser son énergie
à faire et défaire;
Assez flou dans sa mise en œuvre: quels intervenants, quels
livrables ?
 La méthode 2TUP

1'$

2 Track Unified Process

C’est un processus qui répond aux caractéristiques du
Processus Unifié.
Apporte une réponse aux contraintes de changement
continuel imposées aux systèmes d’information de
l’entreprise.
Renforce le contrôle sur les capacités d’évolution et de
correction de tels systèmes.
 La méthode 2TUP

1'$

« 2 Track» signifie littéralement que le processus suit deux

chemins. Il s’agit des «chemins fonctionnels » et « d’architecture
technique », qui correspondent aux deux axes de changement
imposés au système d’information.

* # # * # #
# + / ' #
 La méthode 2TUP

$ 0

' #

#
- " #$
# @
'
# # -
- % +
# + /
La méthode 2TUP
 La méthode 2TUP

7 ) ) # )
/
#
=) ) / )) # )
)
. ) # -
. - / # . +# # ? #
# + / @ ) #
/ - ) # - , #/
) - - # #
% - -
/ # - ) -. #
# # # # /
) #
 La méthode 2TUP

7 ) ) # )
- # #
% +
#") %
+
+
#
- # #
-. # + - + -
)# )#
% %
' # # + /
. # # . # # ) $ -
# ) # # # #
) $ -
- ' # -
" #$ # # #
" #$ ) # #
 La méthode 2TUP dans la pratique
! 0

9# - A A
) ' # # + /
* + - !) ' #
+ * -. # #
# + /
#
* !) ' # -
-- # . +# #

- # - > - # # * -. # #
# # - # # + /
 La méthode 2TUP dans la pratique
2 :

) -$ -$
# # #/ -" /
* !
)
#
#
# # # #

6) #
-. # #
) -
6)# # > - #
 La méthode 2TUP
! 6 %! !

* )# * )# * )#
/ ) - #
-$ -
- ) #D
0 B C # + / ) # #

( # ' # #
-$ / 2 #
( # ' #

)) #-
) # #") * )# (E
 Les apports de la méthode 2TUP

Capitalisation de la connaissance
de l’entreprise

investissement pour le moyen et

long terme
Capitalisation d’un savoir-faire
technique

investissement pour le court et moyen

terme
 Les points forts de la méthode 2TUP

Itératif

Fait une large place à la technologie et à la gestion du risque

Définit les profils des intervenants, les livrables, les plannings,

les prototypes
 Les points faibles de la méthode 2TUP

Plutôt superficiel sur les phases situées en amont et en aval du

développement : capture des besoins, support, maintenance, gestion

du changement…

Ne propose pas de documents types