Plan des cours

 Genie Logiciel
 Positionnement du cours GL
 Introduction au GL
 Différentes étapes du processus de
développement
 Modelisation Orientée Objet
 Paradigme Objet
 UML
2
Introduction au GL

Positionnement du cours GL

3
Donner une définition
 Logiciel : Programming in the small
 Programmation individuelle sur des petits
problèmes

 Algorithmique, langages de programmation,

structures de données, et un peu de
méthodologie

4
Les différentes catégories de logiciel
 Sur mesure (custom)
 Pour un client spécifique
 Générique (generic)
 Vendu sur le marché
• un tableur (spreadsheet), un outil de base de donnée
(database)
• un outil de traitement de texte (word processor)
•…
 Embarqués (embedded)
 exécutent dans du matériel électronique isolé
machine à laver, télévision, lecteur DVD, téléphone mobile,
magnétoscope, four à micro-ondes, réfrigérateur, joueur
MP3, ...
 Difficile à modifier

5
Les différentes catégories de logiciel
 Logiciel à temps réel (real-time)
 systèmes de contrôle et de surveillance
 manipulent et contrôlent le matériel technique
 Réaction immédiate requise
 Environnement souvent très contraignant

 Logiciel de traitement de données (data processing)

 Ils stockent, recherchent, transforment et présentent
l'information aux utilisateurs
 Grandes quantités de données avec des corrélations
complexes, enregistrées dans les bases de données
 Largement utilisés en administration des affaires
 Fiabilité des résultats
 Sécurité dans l’accès aux données

 Quelques fois les 2 aspects sont présents dans un logiciel

6
Les différentes catégories du logiciel
 Les systèmes distribués
 synchronisent la transmission, assurent l’intégrité des
données et la sécurité, ...
 Technologies utilisées
CORBA, DOM/DCOM, SOAP, EJB, …

 Les systèmes de matériel

 Systèmes d'exploitation, exécutions de matériel de
bas niveau

 Les systèmes d'entreprise

décrivent les buts, les ressources, les règles et le
travail réel dans une entreprise

7
La nature du logiciel
 Le logiciel est facile à reproduire
Tout le coût se trouve dans son développement
Pour d’autres produits, la fabrication est souvent le
processus le plus coûteux

 Le logiciel est intangible

Il est difficile d'estimer l’effort de développement

 Le processus de développement est difficile à

automatiser
L’industrie du logiciel exige beaucoup de main d’oeuvre

8
La nature du logiciel
 Même des informaticiens peu qualifié peuvent
arriver à bricoler quelque chose qui semble fonctionner
 La qualité d’un logiciel n’est pas apparente

 Un logiciel semble facile à modifier

 La tentation est forte d’effectuer des changements
rapides sans vraiment en mesurer la portée

 Un logiciel ne s’use pas

 Il se détériore à mesure que des changements sont
effectués (software aging)
 en raison de l’introduction d’erreurs
 ou par une complexification indue

9
La nature du logiciel
Raisons pour lesquelles le logiciel vieillit
 maintenance (e.g., bug fixes)
 érosion architecturale
 inflexibilité dès le début
 documentation insuffisante ou inconsistante
 duplication de code
 manque de modularité
 complexité croissante
 ...

10
La nature du logiciel
 Beaucoup de logiciels sont mal conçus et se
détériorent rapidement

 La demande pour du logiciel est toujours

croissante

 Le logiciel se trouve en perpétuel "état de

crise "

 L’ingénierie du logiciel est une nécessité

 processus systématique au lieu de bricolage

11
Un peu d’histoire …
Années 50 et 60 : programmation empirique
 production "artisanale" de logiciels scientifiques
 royaume des "codeurs" et les "grands gourous"

Fin des années 60 : la "crise du logiciel"

 difficulté d'écrire de grands programmes
 difficulté de les utiliser, difficulté de les faire
évoluer
 de nombreux projets échouent

12
 Quelques statistiques
Étude du gouvernement américain en 1979

 Payés mais jamais livrés $3.2M 45%

 Livrés mais jamais utilisés $2.0M 30%
 Abandonnés ou refaits $1.3M 20%
 Utilisés après modification $0.2M 3%
 Utilisés tel quel $0.1M 2%

13
Échecs: Pannes logicielles
 La sonde vers Vénus s'est perdue dans l'espace.
Cause : une erreur de programme FORTRAN,
virgule remplacée par un point.

 Au passage de l'équateur un F16 se retrouve sur le

dos.
Cause : changement de signe de la latitude mal
pris en compte.

 La lutte contre le bogue de l'an 2000 a coûté à la France

500 milliards de francs.
Cause : la donnée "année" était codée sur deux
caractères pour gagner un peu de place.

14
Approches Méthodologiques
Crise de l'industrie du logiciel à la fin des
années 60 :
 augmentation des coûts
 difficultés d'évolution
 non fiabilité
 non respect des spécifications
 non respect des délais

Importance d'approches méthodologiques

Apparition et développement
du Génie Logiciel
15
Génie Logiciel: définition
 Génie Logiciel : Programming in the
large
 Travail en équipe sur des projets complexes et
longs
 Spécifications de départ « floues »
 Dialogue avec les utilisateurs/clients : discours
métier
 Organisation, planification, gestion du risque

16
Génie Logiciel: définition
 Définition du génie logiciel (GL):
Domaine des ‘sciences de l’ingénieur’ dont la
finalité est:
 la conception
 la fabrication
 la maintenance
de systèmes logiciels complexes, sûrs et de
qualité
(‘Software Engineering’ en anglais)
17
Génie Logiciel: Objectifs
 Objectifs du génie logiciel: CQFD
Le GL se préoccupe des procédés de fabrication des
logiciels de façon à satisfaire les 4 critères suivants:

 Le système qui est fabriqué répond aux

besoins des utilisateurs (correction
fonctionnelle).

18
Génie Logiciel: Objectifs
 La qualité correspond au contrat de service initial. La
qualité du logiciel est une notion multiforme qui
recouvre :

 la validité : aptitude d'un logiciel à réaliser exactement les

tâches définies par sa spécification

 la fiabilité : aptitude d'un logiciel à assurer de manière

continue le service attendu

 la robustesse : aptitude d'un logiciel à fonctionner même

dans des conditions anormales

 l’extensibilité : facilité d'adaptation d'un logiciel aux

changements de spécification
19
Génie Logiciel: Objectifs
 la réutilisation : aptitude d'un logiciel à être
réutilisé en tout ou partie

 la compatibilité : aptitude des logiciels à pouvoir

être combinés les uns aux autres

 l’efficacité : aptitude d'un logiciel à bien utiliser les

ressources matérielles telles la mémoire, la
puissance de l’U.C., etc.

 la portabilité : facilité à être porté sur de

nouveaux environnements matériels et/ou
logiciels

20
Génie Logiciel: Objectifs
 la traçabilité : capacité à identifier et/ou suivre un
élément du cahier des charges lié à un composant
d'un logiciel

 la vérifiabilité : facilité de préparation des

procédures de recette et de certification

 l’intégrité : aptitude d'un logiciel à protéger ses

différents composants conte des accès ou des
modifications non autorisés

 la facilité d'utilisation, d’entretien, etc

21
Génie Logiciel: Objectifs

 Les coûts restent dans les limites prévues

au départ.

 Les délais restent dans les limites prévues

au départ.

Règle du CQFD :
Coût Qualité Fonctionnalités Délai

22
Génie Logiciel: Les 7 principes
fondamentaux
 Rigueur
 Séparation des problèmes
 Modularité
 Abstraction
 Anticipation du changement
 Généricité
 Construction incrémentale

23
Rigueur
Le niveau maximum de rigueur est la
formalité: descriptions et validations
s’appuient sur des notations et lois
mathématiques.

Il n’est pas possible d’être formel tout le

temps : il faut bien construire la première
description formelle à partir de
connaissances non formalisées ! Mais dans
certaines circonstances les techniques
formelles sont utiles.
24
Séparation des problèmes
diviser pour régner : considérer séparément différents aspects
d’un problème afin d’en maîtriser la complexité

 séparation dans le temps (les différents aspects sont

abordés successivement, voir cycle de vie du logiciel)

 séparation des qualités que l’on cherche à optimiser à un

stade donné (ex : assurer la correction avant de se
préoccuper de l’efficacité)

 Séparations des ‘vues’ que l’on peut avoir d’un système (ex
: se concentrer sur l’aspect ‘flots de données’ avant de
considérer l’aspect ordonnancement des opérations ou ‘flot
de contrôle’)

 Séparation du système en parties (un noyau, des

extensions, …)
25
 ...
Modularité
 Un système est modulaire s’il est composé de sous-
systèmes plus simples, ou modules

 La modularité permet de considérer séparément le contenu

du module et les relations entre modules. Elle facilite
également la réutilisation de composants biens délimités

 Un bon découpage modulaire se caractérise par une forte

cohésion interne des modules (ex : fonctionnelle,
temporelle, logique, ...) et un faible couplage entre les
modules (relations inter modulaires en nombre limité et
clairement décrites)

 Programmation par composants

26
Abstraction
 L’abstraction consiste à ne considérer
que les aspects jugés importants d’un
système à un moment donné, en
faisant abstraction des autres aspects

 L’abstraction permet une meilleure

maîtrise de la complexité

27
Anticipation du changement
Un logiciel est presque toujours soumis à des
changements continuels (corrections d'imperfections
et évolutions en fonctions des besoins qui changent)

Ceci requiert des efforts particuliers pour prévoir, faciliter

et gérer ces évolutions inévitables.

Il faut par exemple :

 faire en sorte que les changements soient les plus
localisés possibles (bonne modularité)
 être capable de gérer les multiples versions des
modules et configurations des versions des modules,
constituant des versions du produit complet.

28
Généricité
Il est parfois avantageux de remplacer
la résolution d’un problème spécifique
par la résolution d’un problème plus
général

Utilisation des design pattern (voir dans

les prochaines Années Master)

29
Construction incrémentale
Un procédé incrémental atteint son but
par étapes en s’en approchant de
plus en plus; chaque résultat est
construit en étendant le précédent

30
Introduction au GL

Différentes étapes du processus de

développement: Cycle de Vie Logiciel

Cycle de Vie (Processus Logiciel) :

o démarre par la décision de développement

d’un logiciel
o se termine par la mise hors service du logiciel
31
Étapes du processus de
développement
Analyse des Spécifications
besoins

Analyse du Conception
système

Validation
Implémentation

Maintenance

32
Cycle de Vie « Traditionnel »

POURQUOI ? Pré-Analyse Non => Abandon

Oui + Cahier des charges du Projet

QUOI ? Analyse
Cahier des Charges

COMMENT ? Conception
Découpage en modules Développement
Implémentation

Code

Test
Logiciel opérationnel

Maintenance 33
Répartition du coût de développement

Type du système Besoins - Implémentation Test

conception

Systèmes de 46% 20% 34%

contrôle

Systèmes de 34% 20% 46%

l’aéronautique

Systèmes 33% 17% 50%

d’exploitation

Systèmes 44% 26% 30%

scientifiques

Systèmes de 44% 28% 28%

gestion

34
 Cycle de Vie Logiciel

Avant-projet Exploitation &

Développement Maintenance
de projet

Retrait
Gestion

Initiation Planification, Pilotage & Suivi

du projet
Gestion de qualité Évaluatio
n

Analyse
Activités techniques

Conception

Implémentation

Tests Maintenance
Étude
&
préalable
Installation Assistance

Documentation
Vérification et Validation (V&V)
35
Gestion des configuration
Documentation

 C'est l'enregistrement de tout ce qui pourrait

être connu à propos d'un système.
 Communication entre les différents
intervenants, Développeurs
 Indication de l'évolution et du comportement du système,
Gestion du projet
 Trace de toute prise de décision, toutes les informations
du système, Maintenance
 Utilisation et administration du système, Utilisateurs
 etc..
 Tâche consommatrice de ressources, à
planifier
 Plusieurs types de documentation
36
Vérification & Validation (V&V)

Vérification : « Est ce que nous construisons

bien le produit? »
Validation : « Est ce que nous construisons le
bon produit? »
 Validation des besoins
 => Vérification du respect des spécifications du logiciel et
des besoins
 => Démonstration que les performances réelles sont
conformes aux spécifications de performances
 Vérification de tous les éléments constituant la
fourniture du logiciel : code, rapports,
manuels, documentation, jeux de tests,
etc. 37
Gestion de configuration

Par cette activité on cherche à gérer l’ensemble

des composants d’un logiciel.

 Entrée: les composants + description des

configurations
 Tâches: gérer les composants du système,
leur évolution, leur mise à jour, leur
intégration.
 Sortie: documents décrivant:
 les exécutables
 les configurations
38
Étapes du processus de
développement
Analyse des Spécifications
besoins

Analyse du Conception
système

Validation
Implémentation

Maintenance

39
Analyse des besoins
Étape préalable si le client n’a pas une idée
précise du système à réaliser

 Étude informelle des fonctionnalités (externes)

du système sans considération technique:
Point de vue métier / utilisateur

 Aide au formalisme du problème à résoudre

 Production de documents textuels avec

schémas, graphes, etc.

40
Étapes du processus de
développement
Analyse des Spécifications
besoins

Analyse du Conception
système

Validation
Implémentation

Maintenance

41
Spécifications

Ce que doit faire le système côté client

 Document précis spécifiant les fonctionnalités
attendues (contour fonctionnel)
 Base du contrat commercial avec le client
 Document facile à comprendre par le client /
utilisateur
 (scénarios, interactions, enchaînement
d’écrans)

Les spécifications ne sont jamais complètes

et définitives (évolution du domaine,
besoins supplémentaires, …)
42
Étapes du processus de
développement
Analyse des Spécifications
besoins

Analyse du Conception
système

Validation
Implémentation

Maintenance

43
Analyse du système
Quoi faire ? : comprendre et modéliser le métier
 Réflexion métier hors de toute considération technique
 Reste un support de discussion avec le
client/utilisateur (questions/réponses)
 Premier modèle du système (niveau métier)
Identifier les éléments intervenant (acteurs) hors et
dans le système: fonctionnalités, structure et
relations, états par lesquels ils passent suivant
certains événements
L’analyse n’est jamais complète, mais elle doit être juste
Établissement du cahier des charges
et des contraintes du système
44
Étapes du processus de
développement
Analyse des Spécifications
besoins

Analyse du Conception
système

Validation
Implémentation

Maintenance

45
Conception
Comment faire le système: choix techniques
 Choix d’une architecture technique (matérielle,
logicielle) suivant certaines contraintes (robustesse,
efficacité, performances, portabilité …)
 Expertise informatique: hors compréhension du client
 Modèle de l’architecture logicielle du système
 Décomposition en sous systèmes: application
(interfaces), domaine (métier) et infrastructure
(implémentation)
 Permet la définition des phases d’implémentions, de
validation et de maintenances

Production d’un modèle du système final

en cohérence avec les choix d’architecture
46
Étapes du processus de
développement
Analyse des Spécifications
besoins

Analyse du Conception
système

Validation
Implémentation

Maintenance

47
Implémentation
 Trop de temps consacré à cette phase au
détriment d’analyse et de conception:
mauvaise pratique, parfois très coûteuse …

 Nécessite un savoir de la réutilisabilité des

composants, voir d’outils de génération de
code (voir MDA cours Master)

 L’activité sera de plus en plus tournée vers

la réutilisation des composants existants

48
Étapes du processus de
développement
Analyse des Spécifications
besoins

Analyse du Conception
système

Test
Implémentation

Maintenance

49
Test
 Tests de vérification
 Vérification de la robustesse et cohérence du
système, en particulier dans les cas d’exceptions
 Testeur est différent du concepteur ou du
développeur
 Logiciels de tests: toute ligne de code doit être testée
 Différentes méthodes de validation (voir cours Master
méthodes formelles)

 Recette
 Validation client: accord avec les besoins
 Planification dès spécifications: cahier de recettes

 Activité souvent sous estimée

50
Étapes du processus de
développement
Analyse des Spécifications
besoins

Analyse du Conception
système

Validation
Implémentation

Maintenance

51
Maintenance
 Deux types de maintenance
 Correction des erreurs du système (Curative)
 Demande d’évolution (modification de
l’environnement technique, nouvelle
fonctionnalités …) (Evolutive)(Adaptative)
 Facteurs da qualité essentiels
 Corrections: robustesse
 Évolution: modificabilité, portabilité

 Étape longue, critique et coûteuse

 Une enquête effectuée aux USA en 1986 auprès de
55 entreprises a révélé que 53% du budget total d'un
logiciel est affecté à la maintenance

52
Processus de développement

 Processus de développement
 une certaine modélisation,
décomposition du processus global de
la production de logiciels afin de mieux
maîtriser la complexité, les temps de
réalisation et les coûts
 enchaînement d ’étapes, de sous-
processus
Processus ?
Modèle ? 53
Modèles de Cycle de vie du
logiciel
 modèle de la cascade (plusieurs variantes)

 modèle en V
 modèle du prototypage
 modèle de la programmation exploratoire
 modèle en spirale
 modèle incrémental
 modèle de la transformation formelle
 Modèle MDA en Y (Master Ingénierie des Modèles)
 etc.
54
Modèle de la cascade

Analyse V&V

Conception V&V

Codage V&V

Tests unitaires V&V

Intégration
et Tests V&V

Exploitation /
Maintenance

55
Modèle de la cascade

 Principales caractéristiques du modèle en

cascade :
 Chaque étape du cycle est caractérisé par des ACTIVITES
dont le but est d’élaborer un ou des produits intermédiaires
 Chaque fin d’étape est matérialisé par un événement où
s’exerce une activité de contrôle (VERIFICATION et
VALIDATION) afin d’éliminer au plus tôt les anomalies
des produits réalisés. Le passage à l’étape suivante est
conditionné par le résultat de contrôle (acceptation, rejet,
ajournement)
 Autant que possible, les retours en arrière sur les étapes
précédentes se limitent à un retour sur l’étape
immédiatement antérieure

56
Modèle de la cascade

 Avantages
 Facile à comprendre
 Le plus utilisé dans l’industrie
 Inconvénients
 Approche purement séquentielle et
« simpliste »
 Il est rare que le client puisse fournir toutes les
spécifications dès le début du projet.
 Le client ne reçoit pas les résultats concret
pendant le développement du logiciel

57
Modèle en V

Installation
Analyse
et Tests
V&V
Conception Intégration
Globale et Tests

Conception
Tests unitaires
Détaillée

Codage

58
Modèle en V : Principe

 Les première étapes du cycle doivent préparer

les dernières étapes, essentiellement les
activités de vérification et de validation.
 Deux sortes de dépendances entre étapes :
 Traits continu : correspondent à l’enchaînement et à
l’itération éventuelle du modèle de la cascade, les étapes
se déroulent séquentiellement en suivant le V de gauche à
droite
 Traits non continus : Une partie des résultats de l’étape
de départ est utilisée directement par l’étape d’arrivée.
Par exemple : à l’issue de la conception, le protocole
d’intégration et les jeux de tests d’intégration
doivent être complètement décrits.
59
Modèle en V : Avantages &
Inconvénients
 Avantages :
 Avec toute décomposition doit être décrite la
recomposition, toute description d’un composant
est accompagnée de tests .
 Principe qui évite un écueil bien connu de la
spécification : on énonce une propriété qu’il est
impossible de vérifier objectivement une fois le
logiciel réalisé.
 L’obligation de concevoir les jeux de tests et leurs
résultats oblige à une réflexion et à des retours sur la
description en cours.
 Les étapes de la branche droite du V peuvent être
mieux préparés et planifiés.

 Inconvénients : 60
Modèle du Prototypage

Consulter Construire ou améliorer

le client le prototype

Essai du prototype
par le Client

 Initialement, les spécifications donnés par le

client sont d’ordre général
 Raffinement des spécifications, des
fonctionnalités et performances par des
prototypes successifs.
61
Modèle du Prototypage

 Difficulté de spécifier et valider les besoins

 Principe: construire un prototype pour permettre aux
utilisateurs de l’essayer
1. établir les objectifs du prototype (IU, besoins
fonctionnels, etc.)
2. choisir les fonctions à inclure et les besoins non-
fonctionnels à prendre en compte
3. développer le prototype
4. Évaluer le prototype
 Plusieurs techniques de réalisation
(langage de spécif. Exécutable, langages de
très haut niveau, etc.)
 Coûteux mais rentable à long terme

62
Modèles – Prototypage :
avantages et inconvénients
 Le client participe activement dans le développement du produit;
 Le client reçoit des résultats tangibles rapidement ;
expérimentation rapide ou des fonctions voulue par les utilisateurs
 Introduction d’un feedback immédiat de la part des utilisateurs
 Vérification du comportement réel (mais partiel) du système
 Amélioration de la COMMUNICATION entre d’une part le client et
l’analyste, d’autre part l’analyste et le concepteur

Si l’utilisation du prototype se fait au niveau de l’étape de spécification,

on peut l’envisager pour :
 Raffiner la conception du système
 Évaluer les performances
 Servir d’apprentissage pour les futurs utilisateurs
Inconvenients :
- Le produit n’est souvent pas de qualité commerciale
- Il implique souvent un effort majeur pour rendre le produit
conforme aux normes de l’industrie; 63
Modèle - Prototypage
exploratoire
 Pallier à l’insuffisance des itérations dans le
modèle de la cascade
 Principe : 1 développer un résumé de la spécification
2 construire le logiciel (prototype)
3 utiliser le logiciel
4 evaluation, itérations 2, 3
5 livrer le système
 Modèle adapté aux systèmes IA, spécification
difficile et équipes de développement petites
 Nécessite des techniques et outils pour
itérations rapides
 Mal adapté aux système complexes,
maintenance coûteuse, structure du logiciel
mal définie 64
 Modèles - Prototypage
exploratoire
Analyse
Analyse
et sélection
préliminaire État non
des nouvelles
des besoins satisfaisant
fonctions
Construction
du prototype
Évaluation
expérimentation
État satisfaisant

Expression claire
des besoins réels

Spécifications
définitives
65
Modèles - Prototypage exploratoire:
Cas d’une application
 BOEHM cite l’exemple d’un système d’aide à
la décision pour les systèmes de diagnostic
médical où le simple recensement des
traitements informatiques à effectuer et des
informations à manipuler peut être 100 fois
plus coûteux que la modification du cahier des
charges issu d’une analyse moins poussée.
Cette analyse est suivie par un développement
RAPIDE d’un prototype du système,
permettant une expérimentation. Cette
démonstration concrète avec les futurs
utilisateurs peut servir comme catalyseur pour
révéler les besoins réels, les bonnes idées, etc.66
 Modèle en spiral
Planification

Communication Analyse
avec le client des risques

Ingénierie
Évaluation par
le client
Construction et
déploiement 67
Modèle en spiral : Principe
 Modèle plus général que les autres modèles
 Il met l’accent sur une activité particulière :
l’analyse des risques
 Le modèle est divisé en « région-tâches » qui
sont :
 Communication avec le client et détermination des
objectifs du cycle, des alternatives pour les atteindre, les
contraintes à partir du résultat précédent, analyse
préliminaire des besoins…
 Planification des activités du projet
 Analyse des risques, évaluation des alternatives…
 Ingénierie nécessaire à la réalisation des activités
 Déploiement des activités
 Vérification de la solution retenue par le client et 68
planification du cycle suivant.
Modèle en spiral : Principe …
 Les activités du projet commencent par le
spiral le plus profond
 Chaque tour passe par les région tâches
 L’accomplissement des phases du projet est
le résultat de l’application des tâches prescrites
par les régions
 Un tour du modèle résulte en un prototype
 On obtient un raffinement du produit en
parcourant plusieurs tours du modèle

69
 Modèle en spiral : Exemple
Planification
Analyse
Communication des risques
avec le client

Les phases du modèle

a) Spécification a
du logiciel b
b) Prototype 1 c
Évaluation Ingénierie
c) Prototype 2 d
par le client
d) Produit final

Construction et
déploiement
70
Modèle en spiral : explication
de l’exemple
 Le premier tour résulte de la spécification du logiciel,
les tâches à réaliser pour cette spécification :
 Communiquer avec le client pour obtenir les spécifications
 Planifier le projet et les étapes de l’analyse des spécifications
 Évaluer les risques technologiques des techniques d’analyse
 Décider sur les techniques à utiliser pour l’analyse des
spécifications
 Réalisation proprement dite de l’analyse des spécifications
 Présenter les résultats au client
 On réalisera les autres tours du modèle de la même
façon
 On profitera de la région « planification » pour
réajuster le plan du projet
71
Modèle en spiral : Avantages et
inconvénients
AVANTAGES
 Modèle réaliste et naturel
 Conserve le caractère « étapiste » du modèle
en cascade mais l’intègre dans une approche
itérative
 Le risque est un facteur qui est tenu en compte
explicitement dans ce modèle.
INCONVENIENTS
 Il est difficile de faire comprendre au client le
mode d’opération de ce modèle
 L’évaluation des risques exige une expertise
spécifique 72
Modèle Incrémental : Principe

 Développer des application en étendant

PROGRESSIVEMENT ses fonctionnalités.
 Les spécifications du logiciel sont figées et connues,
l’étape de conception globale est terminée
 La stratégie consiste à développer le logiciel par
extension successives à partir d’un produit
« Noyau » du logiciel.
 Permet d’éviter de TOUT CONCEVOIR, de TOUT
CODER et de TOUT TESTER comme l’approche en
cascade
 Cette technique a des répercussions sur la répartition
des efforts en fonction du temps, puisqu’il existe une
possibilité de recouvrement des étapes. 73
 Modèle Incrémental : Principe

Incrément 1 Conception Conception Programmation Tests

globale détaillée

Conception Conception Programmation …

Incrément 2 globale détaillée

Conception Conception …
Incrément 3
globale détaillée

temps
74
Modèle Incrémental :
Avantages et inconvénients
AVANTAGES
 Chaque développement est moins complexe
 Les intégrations sont progressives
 Il peut y avoir des livraisons et des mises en service après
chaque intégration d’incrément
 Permet d’optimiser le temps et le partage de tâche
(contrairement aux autres modèles)
 Diminution d’effort pendant la phase de tests d’intégration

INCONVENIENTS
 Le risque majeur de ce modèle est de voir remettre en
cause le noyau ou les incréments précédent (définition
globale des incréments et de leurs interactions dès le début
du projet).
 Les incréments doivent être indépendants aussi bien
fonctionnellement qu’au niveau des calendriers de
développement 75
 Modèle de la transformation
formelle

Besoins exprimé
formellement
Code du logiciel

76