ISIGK

Génie logiciel
Génie logiciel
et conduite de projet
p j

Grady Boock : “créer un logiciel, c’est être un scientifique et un artiste”

Edgar Morin : “le tout est plus que la somme des parties”
 un ensemble d’éléments organisés en un tout ne se résume pas à une liste 
d’éléments
Dr  L BAATI 1
 Plan du cours
Plan du cours
• Notions fondamentales
N ti f d t l
• Genèse et objectifs du GL
• Spécification
• Les approches de réalisation
• Les principes du GL
Les principes du GL
• Les activités de réalisation du GL
• Les modèles classiques de développement de logiciel
Les modèles classiques de développement de logiciel
• Les facteurs de qualité des logiciels
• Cycle de vie d’un
Cycle de vie d un projet info
projet info
• Exemple de découpage pour une conduite de projet 
informatique
Dr  L BAATI 2
 Qu’est
Qu est‐ce que le génie logiciel ?
ce que le génie logiciel ?
• Le génie logiciel est un domaine des sciences 
g j
de l’ingénieur dont l’objet d’étude est la 
conception, la fabrication et la maintenance 
des systèmes informatiques complexes
des systèmes informatiques complexes.

Dr  L BAATI 3
 Qu’est
Qu est‐ce qu
ce qu’un
un système ?
système ?
• Un système est un ensemble d’éléments interagissant entre eux 
suivant un certains nombres de principes et de règles dans le but de 
réaliser un objectif
réaliser un objectif.
• La frontière d’un système est le critère d’appartenance au système.
• LL’environnement
environnement est la partie du monde extérieure au système.
est la partie du monde extérieure au système
• Un système est souvent hiérarchisé à l’aide de sous‐systèmes.
• Un système complexe se caractérise par :
Un système complexe se caractérise par :
– sa dimension qui nécessite la collaboration de plusieurs 
personnes ;
personnes ;
– son évolutivité.
• Exemples : une fourmilière, l
Exemples : une fourmilière l’économie
économie mondiale, le noyau linux, . . .
mondiale le noyau linux
Dr  L BAATI 4
 Qu’est
Qu est‐ce qu
ce qu’un
un logiciel ?
logiciel ?
• Un logiciel est un ensemble d’entités nécessaires au fonctionnement d’un 
l l bl d’ é é f d’
processus de traitement automatique de l’information.
• Parmi ces entités, on trouve par exemple :
, p p
– des programmes exécutables ;
– des documentations d’utilisation ;
– des informations de configuration.
• Un logiciel est en général un sous‐système d’un système englobant.
• Il peut interagir avec des clients qui peuvent être :
Il peut interagir avec des clients, qui peuvent être :
– des opérateurs humains (des utilisateurs, des administrateurs, . . . ) ;
– d’autres logiciels ;
g ;
– 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.
i é i i i i
Dr  L BAATI 5
 Qu’est
Qu est‐ce qu
ce qu’un
un logiciel ?
logiciel ?
Le génie logiciel vise à garantir que :
1. la spécification répond aux besoins réels de ses 
p p
clients ;
2 le logiciel respecte sa spécification ;
2. le logiciel respecte sa spécification ;
3. les coûts alloués pour sa réalisation sont 
respectés ;
respectés ;
4. les délais de réalisation sont respectés.

Dr  L BAATI 6
 Introduction
• lle génie logiciel (G.L.) existe depuis bientôt 40 ans
é i l i i l (G L ) i d i bi ô 40
• le GL est né en Europe en octobre 1968, à Garmisch‐
P t ki h
Partenkirchen, sous le nom de soflware
l d fl engineering, 
i i
et sous le parrainage de l'OTAN 

des constations que le logiciel :
• n'était pas fiable,
'ét it fi bl
• était incroyablement difficile de réaliser dans des 
délais prévus
délais prévus
• ne satisfaisaient pas leurs cahiers des charges

Dr  L BAATI 7
 E r r e ur s c é lè br e s
E r r e ur s c é lè br e s . . .
•1°sonde Mariner vers Vénus s'est perdue dans l'espace à cause 
d'une
d une erreur dans un pgm
erreur dans un pgm Fortran.
Fortran

•1971 : lors d'une expérience météorologique en France, 72 
b ll
ballons contenant des instruments de mesure furent détruits tout 
d d f dé
d'un coup à cause d'un défaut dans le logiciel...

•1981 : un problème logiciel retarda de 2 jours le premier 
lancement orbital de la navette spatiale; la navette fut lancée sans 
que l'on ait localisé exactement la cause du problème
que l'on ait localisé exactement la cause du problème

•1990 : dans nuit du 15‐16 décembre 1990, les abonnés de ATT de 
la côte Est des Etats‐Unis furent privés de tout appel longue 
distance à cause d'une réaction en chaîne dans le logiciel du 
réseau due à un changement de version de ce logiciel
réseau due à un changement de version de ce logiciel
Dr  L BAATI 8
 Projets douloureux
Projets douloureux . . .
• 1960
1960 : OS pour gamme IBM 360 : livré en retard, 
OS IBM 360 li é t d
nécessitait plus de mémoire que prévu, prix
• de revient dépassait de beaucoup les estimations, 
de revient dépassait de beaucoup les estimations
premières versions avec erreurs...
• 1970 : Compilateur PL1 chez Control Data : projet 
p p j
avorté
• 1990 : EDF a dû renoncer à la mise en service du 
nouveau système de contrôle commande de
nouveau système de contrôle‐commande de
• ses centrales de 1 400 mégawatts après plusieurs 
années d'efforts
années d efforts de développement
de développement
• 1993 : SNCF a rencontré des difficultés importantes à 
la mise en service du système Socrate
Dr  L BAATI 9
 Génie logiciel : Genèse et objectif
Génie logiciel : Genèse et objectif
• Difficulté de maîtrise des coûts
iffi l é d î i d û
• Difficulté de réalisation de plannings
• Difficulté de maîtrise des délais de réalisation
• Difficulté d’amélioration
Difficulté d amélioration de la productivité et de 
de la productivité et de
la qualité des logiciels
• Difficulté de gestion de projets logiciels de 
Difficulté de gestion de projets logiciels de
grande ampleur (Programming in the Large)
• Nombreux échecs : résultats fournis par les 
Nombreux échecs : résultats fournis par les
logiciels insatisfaisants pour les clients finaux.

Dr  L BAATI 10
 Pourquoi
le Génie Logiciel ?
• LLes premières tentatives de création de logiciels de 
iè t t ti d é ti d l i i l d
grande ampleur ont vite montré les limites d'un travail 
informel d'ingénieurs logiciel:
g g
– Les produits réalisés ne sont pas terminés dans les temps, 
– coutent plus cher que prévus, 
– ne sont pas fiables, 
– peu performants 
– et coutent cher en entretien
et coutent cher en entretien.
• Quand une application est mal conçue ...
– Mise à jour incomplète
Mise à jour incomplète
• 28.09.1998, Dublin
• Upgrade du système de gestion des feux de circulation
• Opération incomplète
Opération incomplète
• Déconnection de 140 feux
Dr  L BAATI 11
 Pourquoi
le Génie Logiciel ?
• Quand une application est mal conçue ...
d li i l
– Introduction de logiciel dans un système simple
• Accélérateur de particules Therac 25, traitement de 
cancers
• 1985‐1987
1985 1987
• Système existant : Thérac 20
– Circuits électroniques de protections spécifiques
Circuits électroniques de protections spécifiques
– Extension de versions antérieures
• Evolution
– Logiciel remplace les circuits de protection
– Dévoile des bugs dans le Thérac 20
• Mauvais dosage des rayons : 6 morts
M i d d 6 t
Dr  L BAATI 12
 Pourquoi
le Génie Logiciel ?
• Quand une application est mal conçue ...
– Nécessité d'analyse précise des besoins
y p
• En particulier en cas d'évolution du produit
– Danger de la modification des éléments de 
Danger de la modification des éléments de
sécurité d'un système
• Validation indispensable
Validation indispensable
– Risque de la réutilisation non contrôlée
– Et pour le grand public :
• Utilité
• Utilisabilité
Dr  L BAATI 13
Le GL entre besoins et réalisations

Dr  L BAATI 14
 Comment spécifier un logiciel ?
Comment spécifier un logiciel ?
• Que doit faire le logiciel ?
– La spécification d’un logiciel peut prendre de 
p g p p
nombreuses formes.
– La complexité et les dimensions de la spécification 
La complexité et les dimensions de la spécification
peuvent varier énormément en fonction de 
ll’environnement
environnement dd’utilisation
utilisation du logiciel et des 
du logiciel et des
objectifs auxquels il répond.

Dr  L BAATI 15
 Quelques exemples de spécifications
Quelques exemples de spécifications

• Un algorithme de tri :
– Entrée : un tableau t.
– Précondition : il existe une relation d
: il existe une relation d’ordre
ordre sur les éléments du tableau.
sur les éléments du tableau
– Sortie : un tableau u.
– Postcondition : u est trié et contient exactement les mêmes éléments 
que t
que t.
• La partie arrière d’un compilateur :
– Entrée : un arbre de syntaxe abstraite P.
– Précondition : le programme est bien typé.
– Sortie : un fichier exécutable E.
– Postcondition : la sémantique de E est la même que celle de P.

==>  Ce sont des spécifications simples dont la conformité aux objectifs 
de leurs clients ne fait aucun doute. (Cela ne rend pas aisée pour
de leurs clients ne fait aucun doute. (Cela ne rend pas aisée pour 
autant leur réalisation.)
Dr  L BAATI 16
 Les spécificités du logiciel
Les spécificités du logiciel
• La construction d’un logiciel diffère de celle d’un 
i d’ l i i l diffè d ll d’
pont car :
– une modification infime peut avoir des conséquences critiques ;
– les progrès technologiques très rapides peuvent rendre un logiciel 
caduque ;
caduque ;
– il est difficile de raisonner sur des programmes ;
– les domaines des entrées des logiciels sont trop grands pour le 
test exhaustif ;
h f
– les défaillances des programmes sont en général dues à des 
erreurs humaines ;
erreurs humaines ;
– on ne sait pas très bien réutiliser les programmes existants ;
– chaque logiciel a son organisation et sa logique propre ;
– . . .
Dr  L BAATI 17
 Quelques exemples de spécifications 
plus complexes
• U
Une interface graphique : Le modèle d’interaction avec le 
i t f hi L dèl d’i t ti l
client est non
• déterministe. Doit‐on spécifier toutes les traces d’exécution 
p
possibles ?
• Un traducteur automatique : Qu’est‐ce qu’un texte anglais 
« bien écrit » ?
« bien écrit » ?
• Un logiciel « boursicoteur » (effectuant des achats et des 
ventes en bourse) :
)
• Comment établir une spécification sans y inclure un modèle 
du système
• financier ?
fi i ?
• Un jeu vidéo : Comment spécifier ce qui est amusant ?

Dr  L BAATI 18
 Les spécificités du logiciel
Les spécificités du logiciel
LLa construction d’un logiciel diffère de celle d’un pont car :
t ti d’ l i i l diffè d ll d’ t
• une modification infime peut avoir des conséquences 
critiques ;
q ;
• les progrès technologiques très rapides peuvent rendre un 
logiciel caduque ;
• il est difficile de raisonner sur des programmes ;
il diffi il d i d
• les domaines des entrées des logiciels sont trop grands 
pour le test exhaustif ;
pour le test exhaustif ;
• les défaillances des programmes sont en général dues à des 
erreurs humaines ;
• on ne sait pas très bien réutiliser les programmes existants ;
• chaque logiciel a son organisation et sa logique propre ;
• . . .
Dr  L BAATI 19
 Réalisation d’un
Réalisation d un logiciel
logiciel
• LLe génie logiciel est un domaine en pleine évolution 
é i l i i l d i l i é l i
qui offre une grande palette d’outils et de méthodes 
pour parvenir à construire du logiciel de qualité
pour parvenir à construire du logiciel de qualité.
• Aucune de ses méthodes ne s’est imposée à ce jour : il 
faut donc prendre du recul sur les concepts et les
faut donc prendre du recul sur les concepts et les 
conseils qu’elles préconisent et utiliser son bon sens 
p
pour les adapter à chaque situation.
p q
• Ces méthodes se distinguent principalement par :
– leur degré de formalisme ;
g
– leur champ d’application ;
– les contraintes de qualité qu’elles ambitionnent.

Dr  L BAATI 20
 Caractérisation du logiciel
g
• Aspects des systèmes informatiques : 
p y q
– Matériel : 
• Équipements
Équipements physiques : processeurs, Mémoires, 
physiques : processeurs Mémoires
périphériques, …etc.
• Représente 20% du coût global.
ep ése te 0% du coût g oba
– Logiciel : 
• Programmes
Programmes : OS, compilateurs, SGBD, bureautique, 
: OS compilateurs SGBD bureautique
gestion, comptabilité, …etc. 
• Occupe 80% du coût global.
Occupe 80% du coût global

Dr  L BAATI 21
 Caractérisation du logiciel
g
• Matériel informatique : 
q
– Fabrication : 
• Assurée par quelques fabricants seulement.
Assurée par quelques fabricants seulement
– Fiabilité : 
• Le matériel est devenu relativement fiable.
L té i l t d l ti t fi bl
– Standardisation : 
• Le marché du matériel est standardisé.

À notre époque, le matériel ne pose pas de 
vrais problèmes !!!
Dr  L BAATI 22
 Caractérisation du logiciel
g
• Logiciel informatique : 
– Nature virtuelle : 
• Le logiciel est un produit immatériel.
– Nature technique : 
• Le logiciel est un objet technique fortement contraint.
– Cycle de production particulier : 
• La reproduction ne pose pas de problèmes, seule la 
p p p p
première copie a un coût.

Les problèmes liés à l’informatique sont
essentiellement des problèmes de logiciel !!!
Dr  L BAATI 23
 Caractérisation du logiciel
g
• La « crise du logiciel » : 
g
– Étude sur 8 380 projets de fabrication de logiciels 
(Standish Group, 1995) :
(Standish Group, 1995) : 
• Succès : 16%;
• Problématique : 53% (budget ou délais non respectés, 
Problématique : 53% (budget ou délais non respectés
défaut de fonctionnalités);
• Échec : 31% (projets abandonnés).
Échec : 31% (projets abandonnés).

Le taux de succès décroît avec la taille des projets
et la taille des entreprises
et la taille des entreprises
Dr  L BAATI 24
 Caractérisation du logiciel
g
• Le génie logiciel (Software Engineering) : 
g g g g
– Objectifs : 
• Comment
Comment faire des logiciels de qualité ?
faire des logiciels de qualité ?
• Définir et spécifier les critères de qualité logicielle.
• Maîtriser le processus de fabrication de logiciels.
Maîtriser le processus de fabrication de logiciels

Définition : le génie logiciel regroupe les sciences et 
les technologies qui permettent la construction de
logiciels de qualité.
Dr  L BAATI 25
Les approches de 
réalisation du GL
réalisation du GL

Dr  L BAATI 26
 Approches de réalisation (1)
Approches de réalisation (1)
• Les 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, VHDL, Atelier B, CASL, Why, 
Frama‐C, . . .
– Ces méthodes sont utilisées pour développer des logiciels 
critiques.
iti
– Elles correspondent au niveau le plus élévé de certification.

Dr  L BAATI 27
 Approches de réalisation (2)
Approches de réalisation (2)
• Les approches semi‐formelles visent à introduire un langage normalisé pour 

décrire le logiciel et sa spécification.

• Cependant la sémantique du langage de spécification n’est pas formalisée

Cependant, la sémantique du langage de spécification n’est pas formalisée.

• Bien que ces approches 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.

• Méthodes : Rationale Unified Process, Merise, . . .

• O til t t ti
Outils et notations : UML, AnalyseSI, . . .
UML A l SI

• Ces méthodes sont utilisées aujourd’hui par l’industrie du logiciel.

Dr  L BAATI 28
 Approches de réalisation (3)
Approches de réalisation (3)
• Les approches empiriques mettent en avant 
p q q
un ensemble de “bonnes pratiques” qui ont 
fait leur preuve par l’expérience.
• Méthodes : relecture de code, extreme
Méthodes : relecture de code extreme
programming, programmation défensive, . . .
• Outils : gestionnaire de versions, outil de 
documentation automatique, . . .
documentation automatique, . . .

Dr  L BAATI 29
Principes du GL
Principes du GL

Dr  L BAATI 30
 Les grands principes du génie logiciel
Les grands principes du génie logiciel
• Un certain nombre de grands principes (de bon 
i b d d i i (d b
sens) se retrouvent dans toutes ces approches :
1. La rigueur.
2. La décomposition des problèmes en sous‐problèmes 
i dé
indépendants.
d t
3. La modularité.
4 L’ b
4. L’abstraction.
i
5. L’anticipation des évolutions.
6
6. La généricité.
é éi ié
7. La construction incrémentale.

Dr  L BAATI 31
 La rigueur
La rigueur
• Les principales sources de défaillances d’un logiciel 
es p c pa es sou ces de dé a a ces d u og c e
sont d’origine humaine.
• À tout moment, il faut se questionner sur la 
Àt t t il f t ti l
validité de son action.
• Des outils de vérification accompagnant le 
développement peuvent aider à réduire les
développement peuvent aider à réduire les 
erreurs. Cette famille d’outils s’appelle CASE 
(Computer Aided Software Engineering).
(Computer Aided Software Engineering)
• Exemples : typeurs, assistants de preuves, 
générateurs de code, générateurs de tests. . .
Dr  L BAATI 32
 La décomposition des problèmes en 
sous‐problèmes
• « Separation of concerns » en anglais.
• Il s
Il s’agit
agit de :
de :
– Décorréler les problèmes pour n’en traiter qu’un 
seul à la fois
seul à la fois.
– Simplifier les problèmes (temporairement) pour 
aborder leur complexité  progressivement.
b d l l ié i

Dr  L BAATI 33
 La modularité
La modularité
• C’
C’est une instance cruciale du principe de décomposition 
t i t i l d i i d dé iti
des problèmes.
• Il s’agit de partitionner le logiciel en modules qui :
g p g q
– ont une cohérence interne (des invariants) ;
– possèdent une interface ne divulguant sur le contenu du 
module que ce qui est strictement nécessaire aux modules
module que ce qui est strictement nécessaire aux modules 
clients.
• L’évolution de l’interface est indépendante de celle de 
l’i lé
l’implémentation du module.
t ti d d l
• Les choix d’implémentation sont indépendants de 
l’utilisation du module.
• I Ce mécanisme s’appelle le camouflage de l’information 
(information hiding).

Dr  L BAATI 34
 L abstraction
L’abstraction
• C’
C’est encore une instance du principe de 
t i t d i i d
décomposition des problèmes.
• Il s
Il s’agit
agit d
d’exhiber
exhiber des concepts généraux regroupant un 
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.
ti li
• Le fait de fixer la bonne granularité de détails permet :
– de
de raisonner plus efficacement ;
raisonner plus efficacement ;
– de factoriser le travail en instanciant le raisonnement 
général sur chaque cas particulier.
Exemples en programmation : les classes abstraites dans 
les langages à objets, le polymorphisme de Caml, les 
fonctions d’ordre
fonctions d ordre supérieur.
supérieur
Dr  L BAATI 35
 LL’anticipation
anticipation des évolutions
des évolutions
• Un
Un logiciel a un cycle de vie plus complexe que l
logiciel a un cycle de vie plus complexe que l’habituel
habituel 
cycle « commande‐spécification‐production‐livraison ».
• La maintenance est la gestion des évolutions du logiciel.
La maintenance est la gestion des évolutions du logiciel.
• Il est primordial de prévoir les évolutions possibles d’un 
g p q p
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.
é éd t lid ti
• Concevoir un système suffisamment riche pour que l’on 
puisse le modifier incrémentalement est l’idéal.
puisse le modifier incrémentalement est l’idéal
Dr  L BAATI 36
 La généricité
La généricité
• Un logiciel réutilisable a beaucoup plus de 
q p
valeur qu’un composant dédié.
• Un composant est générique lorsqu’il est 
adaptable.
adaptable

Dr  L BAATI 37
 La construction incrémentale
La construction incrémentale
• Un développement logiciel a plus de chances 
dé l l i i l l d h
d’aboutir si il suit une cheminement incrémental 
(b b t )
(baby‐steps).
Exemple :
• Laquelle de ses deux méthodes de 
programmation est la plus efficace ?
1. Écrire l’ensemble du code source d’un programme et 
compiler.
2. Écrire le code source d’une fonction, le compiler et 
passer à la suivante.

Dr  L BAATI 38
 Les activités de 
Les activités de
développement du génie
développement du génie 
logiciel

Dr  L BAATI 39
 Les activités de développement du 
génie logiciel
Les Activités du GL
• Analyse des besoins
Analyse des besoins
• Spécification globale
• Conceptions architecturale et détaillée
• Programmation
• Gestion de configurations et intégration
• Validation et vérification

Dr  L BAATI 40
 Analyse des besoins
Analyse des besoins
• Objet
– éviter de développer un logiciel non adéquat
– menée en liaison avec les études de faisabilité et la planification
– étude du domaine d'application : états actuel et futur de l'environnement 
du système, déterminer les frontières, le rôle, les ressources disponibles et 
requises, les contraintes d'utilisation et de performance, etc.
• Données
– fournies par des experts/utilisateurs du domaine d'application
‐> établir un dialogue entre informaticiens et experts/utilisateurs du 
domaine méthodes utilisées : relèvent plutôt des sciences cognitives : 
entretiens, questionnaires,
i i i
– observations de l'existant, études de situations similaires
• Résultat
– ensemble de documents décrivant l'environnement du futur système, son 
rôle et sa future utilisation (parfois manuel d'utilisation préliminaire)

Dr  L BAATI 41
 Spécification globale
Spécification globale
• Objet
– établir une première description du futur système, corrélée avec :
• l'analyse des besoins (souvent regroupées dans même étape)
• la validation
l lid ti
• Données
– résultats de l'analyse des besoins + considérations 
t h i
technique/faisabilité informatique
/f i bilité i f ti
• Résultat : spécification technique de besoins STB
– le quoi, pas le comment :
• une description de ce que doit faire le logiciel en évitant des décisions 
prématurées de réalisation
• trop difficile d'anticiper leurs conséquences sur la réalisation finale en termes 
de pe o a ces, essou ces, ou ê e de a sab té
de performances, ressources, ou même de faisabilité.
– point de départ au développement
– souvent : 1° version du manuel de référence + compléments au 
manuel d'utilisation.

Dr  L BAATI 42
Des besoins du client à la spécification 
du système qui les satisfait
• LLa spécification établit ce que le système doit faire (le 
é ifi ti ét blit l tè d it f i (l
QUOI) et les contraintes sous lesquelles il doit opérer.
• LL’ingénierie
ingénierie de la spécification consiste donc établir 
de la spécification consiste donc établir
une communication entre les clients et les concepteurs 
du systèmes.
• Comme tout processus de communication, il s’agit 
donc d’un échange d’informations ayant pour support 
un canal de communication entre plusieurs entités
un canal de communication entre plusieurs entités.
– Quelles sont ces entités ?
– Quelle information doit être échangée ?
– Quels sont les canaux de communication à notre 
disposition ?
disposition ?
Dr  L BAATI 43
 Des spécifications de natures diverses
Des spécifications de natures diverses
• I Il est essentiel de dissocier dans la description d’un système, les deux 
p
points de vue :
– interne (celui des concepteurs, des personnels techniques, . . . ) ;

– externe
t ( l id
(celui des utilisateurs non informaticiens, des décideurs, . . . ).
tili t i f ti i d dé id )

• Pour le point de vue externe, on définit une spécification des besoins : 
une description de haut‐niveau d’abstraction des services que doit rendre 
y q p
le système et les contraintes sous lesquelles il opère.

• Pour le point de vue interne, on définit une spécification du système : une 
description la plus précise possible du système qui doit être réalisé.
Dr  L BAATI 44
Comment définir la spécification
Comment définir la spécification

Dr  L BAATI 45
 Spécifications fonctionnelles
Spécifications fonctionnelles 
• Lors de l'écriture du cahier des charges, il est recommandé de 
séparer les spécifications fonctionnelles des spécifications non‐
séparer les spécifications fonctionnelles des spécifications non‐
fonctionnelles. 
• Les spécifications fonctionnelles décrivent les fonctions (ou les 
opérations, ou encore les transformations) que le logiciel doit 
é l f ) l l ld
réaliser. 
– Chaque
Chaque fonction est décrite en détail, en spécifiant ses entrées et ses 
fonction est décrite en détail, en spécifiant ses entrées et ses
sorties. 
– Spécifier les valeurs légales pour les entrées, ainsi que le 
comportement du programme pour les entrées illégales.
comportement du programme pour les entrées illégales. 
– Spécifier le comportement du logiciel en cas de problèmes avec le 
matériel (par exemple, panne de périphérique, panne du processeur 
qui peut avoir des conséquences sur la cohérence d'informations
qui peut avoir des conséquences sur la cohérence d informations 
stockées sur un fichier, etc.). 
• Toutes ces spécifications ne doivent décrire que le 
comportement externe du logiciel
comportement externe du logiciel. 
Dr  L BAATI 46
 Spécifications non fonctionnelles
Spécifications non fonctionnelles 
• LLes spécifications non‐fonctionnelles sont toutes les 
é ifi ti f ti ll tt t l
spécifications qui n'expriment pas une fonction du logiciel. 
Ces spécifications, qui expriment des contraintes, sont 
essentiellement de deux types: 
– les contraintes d'interface. Les contraintes imposées par 
l'environnement logiciel
g (par exemple: le programme doit 
(p p p g
s'exécuter sur tel système d'exploitation), par l'environnement 
matériel (par exemple: le programme doit utiliser les 
caractéristiques de tel terminal) ou par l'environnement humain
(
(par exemple: les commandes mises à disposition doivent 
l l d àd d
satisfaire telle ou telle contrainte); 
– les contraintes de performance. Il s'agit par exemple de 
contraintes de mémoire (mémoire principale ou disque), de 
temps de réponse, des contraintes de sécurité, etc. 

Dr  L BAATI 47
 Plan pour un cahier des charges (1)
Plan pour un cahier des charges (1) 
• Le cahier des charges, qui est souvent un document volumineux, se doit de 
respecter une certaine structure: 
t t i t t
• 1. Introduction : L'introduction présente le logiciel à réaliser en terme de 
besoins (à quoi va servir le logiciel), et décrit brièvement ses fonctions 
principales. L'introduction permet également de présenter les éventuelles 
i i l L'i d i é l d é l é ll
notations utilisées dans la suite du document ainsi que le plan de ce même 
document. 
• 2. Matériel
é l : Cette section permet de décrire le matériel particulier utilisé 
d dé l é l l l é
(par exemple certains périphériques), ainsi que les interfaces. 
• 3. Modèle conceptuel : Le modèle conceptuel donne une vue d'ensemble 
du logiciel à réaliser . 
• 4. Besoins fonctionnels : functional requirements. 
Les spécifications fonctionnelles décrivent les fonctions (ou les opérations, 
ou encore les transformations) que le logiciel doit réaliser. 
• 5. Besoins non fonctionnels : non functional requirements. 
Les spécifications non fonctionnelles sont toutes les spécifications qui 
p p q
n'expriment pas une fonction du logiciel. Ces spécifications expriment des 
contraintes. Dr  L BAATI 48
 Plan pour un cahier des charges (2)
Plan pour un cahier des charges (2) 
• 6. Sous ensemble et priorités d'implémentation : Cette 
section permet de définir d'éventuelles versions 
particulières du logiciel, versions correspondant à des 
sous‐ensembles
sous ensembles des spécifications décrites aux points 3, 4 
des spécifications décrites aux points 3 4
et 5. Avoir rapidement certaines parties du logiciel 
opérationnelles peut être utile. Cette section permet, 
entre autre, de préciser un ordre de réalisation. 
t t d é i d d é li ti
• 7. Information de maintenance : Il se peut que, une fois 
le logiciel opérationnel certaines parties soient davantage
le logiciel opérationnel, certaines parties soient davantage 
susceptibles d'évoluer que d'autres (évolution du 
matériel, changement des besoins des utilisateurs, etc). 
L'i di
L'indiquer dans le cahier des charges permet de construire 
d l hi d h d i
le logiciel de manière à faciliter son évolution. 
• 8. Glossaire
8 Glossaire : Le glossaire contient la définition des termes 
: Le glossaire contient la définition des termes
techniques utilisés dans le cahier des charges.
Dr  L BAATI 49
 Conceptions architecturale et 
détaillée
• Objet
une description du logiciel très proche d'un programme avec détails 
d'implémentation, 2 étapes :
1 Conception architecturale :
1 ‐ Conception architecturale :
– décomposer le logiciel en composants plus simples
– préciser les interfaces et les fonctions de chaque composant
– fournir une description de l
fournir une description de l'architecture
architecture du logiciel et un ensemble de 
du logiciel et un ensemble de
spécifications de ses divers composants.
2 ‐ Conception détaillée :
– fournir
fournir pour chaque composant une description précisant comment ses fonctions 
pour chaque composant une description précisant comment ses fonctions
sont réalisées : algorithmes, représentation des données,...
• Remarques
– frontière entre spécification et conception souvent floue car pas raisonnable de 
p p p
spécifier  un système indépendamment de toute considération de faisabilité.
– la conception commence souvent pendant la spécification, et peut la remettre 
en cause
– des contraintes de réalisation peuvent anticiper sur la conception au moment de 
des contraintes de réalisation peuvent anticiper sur la conception au moment de
la spécification
Dr  L BAATI 50
 Programmation
• passer du résultat de la conception détaillée à 
p g
un ensemble de programmes ou de 
composants de programmes
• la mieux maîtrisée et la mieux 
la mieux maîtrisée et la mieux "outillée"
outillée  
(parfois automatisée)

Dr  L BAATI 51
 Gestion de configurations
Gestion de configurations
• permettre la gestion des composants du 
g
logiciel, d'en maîtriser l'évolution et les mises 
à jour tout au long du processus de 
développement (documentation homogène)
développement (documentation homogène)

Dr  L BAATI 52
 Intégration
• Assembler
Assembler tout ou partie des composants 
tout ou partie des composants
logiciels pour obtenir un système exécutable
• Existe souvent plusieurs choix possibles pour 
certains composants ‐> variantes du logiciel 
(ex: pour des systèmes d'exploitation différents)
• Utilise la gestion de configuration pour :
Utilise la gestion de configuration pour :
– assembler des versions cohérentes de composants
– gérer des variantes du logiciel

Dr  L BAATI 53
 Validation
• A‐t‐on décrit le "bon" système, c'est‐à‐dire un 
y q p
système qui répond à l'attente des 
utilisateurs et aux contraintes de leur 
environnement ?
environnement ?
– s'assurer de l'adéquation des résultats de l'analyse 
des besoins et de la spécification globale
des besoins et de la spécification globale
– consiste en des revues et inspections de 
spécifications ou de manuels, et du prototypage 
é f d l d
rapide

Dr  L BAATI 54
 Vérification
le développement est‐il correct par rapport à la spécification de départ ?
• s'assurer que les descriptions successives du logiciel, et, en fin le logiciel 
lui‐même, satisfont la spécification globale : inspections de 
spécifications, de programme, preuve et tests.
• preuve : porte sur une spécification détaillée ou un programme et 
p p p p g
permet de prouver que celle‐ci ou celui‐ci satisfait bien la spécification de 
départ.
• test : consiste à rechercher des erreurs dans une spécification ou un 
p
programme par :
– examen ou analyse du texte (test statique)
– par des exécutions sur sous‐ensemble fini de données (test dynamique) :
p ( y q )
• test unitaire : tester des composants isolés ;
• test d'intégration : tester un ensemble de composants venant d'être assemblés
• test système : tester le système sur son futur site d'exploitation, dans des conditions 
opérationnelles et au‐delà (surcharge, défaillances matérielles, ... ).
é i ll d là ( h déf ill é i ll )

Dr  L BAATI 55
 Rôle du maquettage ( ou prototypage rapide )
Rôle du maquettage ( ou prototypage rapide )
• principale
principale difficulté en validation 
difficulté en validation = ll'imprécision
imprécision des besoins
des besoins et 
et
des caractéristiques du système à développer
• développer très rapidement un programme, la maquette, qui 
est ne éba che d f t r tè
est une ébauche du futur système et de préciser les besoins
td é i l b i
– elle n'en a pas les performances,
– ni toutes les fonctionnalités et
– elle ne répond pas aux exigences de qualité d'un produit fini.
• maquette exploratoire : soumise à des scénarios en liaison 
avec les futurs utilisateurs afin de préciser leurs besoins ou
avec les futurs utilisateurs afin de préciser leurs besoins ou 
leurs souhaits
• maquette expérimentale : lors d'une étape de conception, 
q p p p ,
permet l'expérimentation et la comparaison de choix différents
Important de bien définir les objectifs d'une opération de 
prototypage rapide, et d'en tenir compte pour la conception de 
la maquette Dr  L BAATI 56
Définition du cycle de vie
Définition du cycle de vie

Dr  L BAATI 57
 Les Cycles de vie de développement 
industriel de logiciels
• qu’est‐ce qu’un cycle de vie logiciel?
q ’est ce q ’ n c cle de ie logiciel?
– Enchaînement des activités de développement logiciel
– Définition des Pré et Post conditions pour chaque phase
– Procédures de gestion et d’encadrement
– Procédures de mesures
– Cycle de vie logiciel : synonyme de méthodologie logiciel
• Etapes d’un cycle de vie
– Analyse : opportunité fonctionnelle et faisabilité technique
– Conception : choix tactiques de réalisation et d’architecture
Conception : choix tactiques de réalisation et d architecture
– Codage : réalisation informatique du détail des opérations
– Test : tests unitaires et d’intégration
– + Exploitation / Maintenance
+ Exploitation / Maintenance
• Les deux grandes catégorie de cycles de vie :
– Les cycles linéaires : succession d’étapes ordonnées
– Les cycles itératifs : réalisation incrémentale par évolutions
Dr  L BAATI 58
 Quelques idées sur les coûts
Quelques idées sur les coûts...
• Répartition : (Ref. Boehm)
Répartition : (Ref. Boehm)
– Analyse/Conception
• " 33‐34 % : Système d’exploitation, Aérospatiale
• " 44‐46 % : Contrôle et Régul. indus., Calcul scientifique, Gestion
" 44 46 % C t ôl t Ré l i d C l l i tifi G ti
– Codage
• " 17‐20 % : Système d’expl., Contrôle et Régul. indus., Aérospatiale
y p g p
• " 26‐28 % : Calcul scientifique, Gestion
– Test/Intégration
• " 28‐34 % : Contrôle et Régul. indus., Calcul scientifique, Gestion
28 34 % : Contrôle et Régul indus Calcul scientifique Gestion
• " 46‐50 % : Système d’exploitation, Aérospatiale
– Maintenance
• " coûts très importants...
• Peu de capitaux d’investissement nécessaires
• Frais de personnel élevés
Frais de personnel élevés
Dr  L BAATI 59
 Quelques chiffres…d'efforts et de 
coûts
• Répartition générales des efforts :
% de l'effort
% de l effort total de développement d
total de développement d'un
un logiciel :
logiciel :
– programmation : 10 à 20%
– spécification et conception : environ 40%
é ifi i i i 40%
– validation et vérification : de l'ordre de 40%

Dr  L BAATI 60
 Coûts selon les domaines 
d'application (pourcentage)

Dr  L BAATI 61
Quelques thèmes tirés par le Génie 
Logiciel

Dr  L BAATI 62
 Les modèles classiques de 
Les modèles classiques de
développement du GL
pp
• Modèle en cascade
• Modèle en V
Modèle en V
• Modèle en W
• Modèle en spirale
• Modèle incrémental
Modèle incrémental

Dr  L BAATI 63
 Le Modèle de la Cascade ( water‐fall model )
modèle très simple nécessite d'avoir
modèle très simple, nécessite d avoir un certain nombre d
un certain nombre d'étapes
étapes (Boehm 76)
(Boehm 76)

Dr  L BAATI 64
 Modèle en cascade
Modèle en cascade
• une étape doit se terminer à une certaine date, par la production de certains 
documents ou logiciels.
• les résultats de l'étape sont soumis à une revue approfondie, et on ne passe 
à l'ét
à l'étape suivante que quand ils sont jugés satisfaisants.
i t d il tj é ti f i t
• certaines étapes portent le nom d'une activité essentielle pour cette étape, 
mais n'impose
mais n impose pas qu
pas qu'elle
elle n
n'ait
ait lieu que dans cette étape.
lieu que dans cette étape.
• d'autres activités interviennent : le contrôle technique ou la gestion de 
configurations présents tout au long du processus.
• les flèches ascendantes (versions actuelles) expriment qu'une étape ne 
remet en cause que l'étape précédente:
‐> en pratique: souvent un vœu pieux, il y a toujours des problèmes qui se 
> en pratique: souvent un vœu pieux il y a toujours des problèmes qui se
propagent de bas en haut
– documents, normes, recommandations décrivent précisément les étapes (IEEE, 
AFNOR).
Dr  L BAATI 65
 Modèle en cascade
Modèle en cascade
• P
Projets de petite taille,
j d i ill
• Projets de back‐office
• Démarche basée sur la spécialisation des tâches qui 
tendent à contenir les risques et les coûts dans un 
enchainement de phases qui reste simple et intuitif
enchainement de phases qui reste simple et intuitif.
• Limites du modèle
– souvent abandonné au profit du modèle en V, plus réaliste 
t b d é fit d dèl V l é li t
dans l'articulation entre les activités de réalisation et de 
validation/vérification.
– Problème de l’effet tunnel où l’on ne voit tourner quelque 
chose qu’à la fin. => Détection d’erreurs tardive

Dr  L BAATI 66
Modèle en V
Modèle en V

Dr  L BAATI 67
 Cycle de vie
linéaire
Cycle en V : variante courante du cycle en cascade

Problème de l’effet tunnel où l’on ne voit tourner quelque chose qu’à la 
P blè d l’ ff t t l ù l’ it t l h ’à l
fin. => Détection d’erreurs tardive
Dr  L BAATI 68
 Modèle en V
Modèle en V
• 2 sortes de dépendances entre étapes :
– celles
celles du V : enchaînement et l
du V : enchaînement et l'itération
itération éventuelle du modèle de la 
éventuelle du modèle de la
cascade les étapes se déroulent séquentiellement en suivant le V de 
gauche à droite
– celles transversales : une partie des résultats de l
celles transversales : une partie des résultats de l'étape
étape de départ 
de départ
est utilisée directement par l'étape d'arrivée
exemple:
à l'issue de la conception architecturale, le protocole 
d'intégration et les jeux de test d'intégration doivent être 
complètement décrits.
p
• évite d'énoncer une propriété impossible à vérifier 
objectivement une fois le logiciel réalisé:
j f g
– avec toute décomposition doit être décrite la recomposition,
– toute description d'un composant est accompagnée des tests qui 
permettront de s'assurer
permettront de s assurer qu
qu'ilil correspond à sa description
correspond à sa description
Dr  L BAATI 69
Les modèles de développement :
modèle en W

Définition des 
besoins bruts Spécifications Test d ’acceptation

Conception de
haut niveau Maquettes Test du système

Conception du
Vérification des système Test du composant
flux logiques
flux logiques i
Conception du
composant i
Codage du com
Codage du com‐
posant i
Dr  L BAATI 70
Modèle en spirale
Modèle en spirale

Dr  L BAATI 71
 Modèle en spirale
Modèle en spirale
• Quadrant 1
d
– Détermination des objectifs, des alternatives et 
des contraintes
• Quadrant 2
– Evaluation, identification et résolution
• Quadrant 3
Quadrant 3
– Développement, Vérification
• Quadrant 4
Q d t4
– Planification des phases suivantes

Dr  L BAATI 72
 Modèle en spirale
Détermination des  Evaluation, 
objectifs, des  identification 
alternatives et des  et résolution
contraintes

Planification des  Développement, 
pp ,
phases suivantes Vérification
Dr  L BAATI 73
 Modèle en spirale
Modèle en spirale
• met l'accent sur l'analyse de risque
y q
• chaque cycle de la spirale se déroule en 4 phases représentées par 4 
quadrants :
– 1. Détermination :
1. Détermination :
• des objectifs du cycle,
• des alternatives pour les atteindre,
• des contraintes, à partir des résultats des cycles précédents, ou, si il n'y en a 
pas, d'une analyse préliminaire des besoins
– 2. Analyse des risques, évaluation des alternatives, éventuellement 
maquettage
– 3. Développement et vérification de la solution retenue
3 Dé l t t é ifi ti d l l ti t
– 4. Revue des résultats et planification du cycle suivant.
• quadrant 3 correspond à un développement classique, et un des 
modèles précédents (de la cascade ou en V) peut s'appliquer
dèl é éd (d l d ) ' l
• ce "super" modèle permet d'encadrer le développement 
proprement dit par des phases consacrées à la détermination des 
objectifs et à l'analyse de risque.
Dr  L BAATI 74
 Modèle en Spirale: risques majeurs 
du développement de logiciel
fournit liste de risques encourus dans développement de logiciel et suggère  des solutions:
fournit liste de risques encourus dans développement de logiciel et suggère des solutions:
• Défaillance de personnel : embauche de personnel de haut niveau; adéquation entre 
profil et fonction ; esprit d'équipe ; formation mutuelle ; personnes clés.
• Calendrier et budget irréalistes : estimation détaillée des coûts et calendriers 
Calendrier et budget irréalistes : estimation détaillée des coûts et calendriers
développement incrémentai ; réutilisation ; élagage des besoins.
• Développement de fonctions inappropriées : analyse de l'organisation, de la mission; 
revues d'utilisateurs; manuel d'utilisation précoce
• Développement d'interfaces utilisateurs inappropriées : maquettage ; scénarios et revues 
Dé l d'i f ili i ié é i
d'utilisateurs ; analyse des tâches.
• Produit "plaqué or" : élagage des besoins ; maquettage ; analyse des coûts bénéfices ; 
conception prenant en compte les coûts.
p p p
• Volatilité des besoins: seuil élevé de modification ; masquage d'information 
développement incrémentai où les derniers incréments sont les plus changeants.
• Composants externes manquants : inspections; essais/mesures; analyse de compatibilité
• Tâches externes défaillantes : audit avant attribution de sous‐traitance ; contrats avec 
bonus ; revues.
• Problèmes de performances: simulations ; modélisations ; essais et mesures 
maquettage.
maquettage
• Exigences démesurées par rapport à la technologie: analyses techniques de faisabilité ; 
maquettage. Dr  L BAATI 75
 le Modèle de la S pi r a le : mis e e n 
œuvre 
• le premier cycle :
le premier cycle :
– une analyse préliminaire de besoins affinée au cours des premiers 
cycles, en prenant en compte les contraintes et l'analyse des risques.
– une utilisation systématique de maquettes exploratoires.
tili ti té ti d tt l t i
• les cycles suivants :
– les
les 3
3°quadrants
quadrants = conception, les choix guidés par maquettes 
conception, les choix guidés par maquettes
expérimentales.
• le dernier cycle se termine par la fin d'un processus de 
développement classique
développement classique
• en conclusion
– mise en œuvre demande des compétences et un effort importants
p p
– moins expérimenté et moins documenté que les précédents .
– utilisation complète adaptée à des projets innovants, à risques, et 
dont les enjeux sont importants
dont les enjeux sont importants.
Dr  L BAATI 76
 Modèle par incrément
Modèle par incrément
•modèles précédents :
•décomposition en composants (conception architecturale) puis
•composants développés indépendamment les uns des autres, en parallèle 
ou en séquence, selon les ressources disponibles
q , p
•modèles par incréments :
un seul sous‐ensemble des composants est développé à la fois :
un logiciel noyau est tout d
•un logiciel noyau est tout d'abord
abord développé puis
développé puis
•des incréments sont successivement développés et intégrés

Dr  L BAATI 77
Les modèles de développement :
développement évolutif
Version n 

Détermination des besoins

Programmation

Expérimentation

Version n +1
Dr  L BAATI 78
Quelques constatations: coût de 
correction des erreurs

Dr  L BAATI 79
 Quelques constatations: 
Recouvrement souhaitable des phase

Dr  L BAATI 80
Quelques constatations: facteurs 
affectant le coût du logiciel

Dr  L BAATI 81
 Modèles par Incréments : avantages
• chaque développement est moins complexe
• les intégrations sont progressives
• livraisons et mises en service possibles après chaque intégration 
livraisons et mises en service possibles après chaque intégration
d'incrément.
• permet de mieux lisser dans le temps l'effort de développement et 
l
les effectifs.
ff tif
• souvent utilisée pour de grands projets, fonctionnant par appels 
d'offres et sous‐traitances.
• Modèles par Incréments : risques
– risque majeur : remise en cause du noyau ou les incréments 
précédents
– autre risque : être incapable d'intégrer un incrément.
• En conséquence :
En conséquence :
– au début du projet, spécification globale du noyau, des incréments, et 
de leurs Interactions
– incréments aussi indépendants que possible (aussi bien 
incréments aussi indépendants que possible (aussi bien
fonctionnellement qu'au niveau des calendriers de développement)
Dr  L BAATI 82
 Comment fabriquer un logiciel de 
qualité ?
Historiquement, il y a eu une prise de conscience dans les années 70, 
appelée la crise du logiciel, dû à un tournant décisif : c’est à cette 
époque que le coût de construction du logiciel est devenu plus
époque que le coût de construction du logiciel est devenu plus 
important que celui de la construction du matériel.

The major cause of the software crisis is that the machines have 
become several orders of magnitude more powerful ! To put it quite 
bluntly : as long as there were no machines, programming was no
bluntly : as long as there were no machines, programming was no 
problem at all ; when we had a few weak computers, programming 
became a mild problem, and now we have gigantic computers, 
programming has become an equally gigantic problem. 
i h b ll i i bl

Edsger Dijkstra, The Humble Programmer (EWD340)
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html
Dr  L BAATI 83
 Les facteurs de qualité d’un logiciel
q g
• Les facteurs de qualité d’un logiciel : 
– Correction : 
• Le logiciel assume correctement ses fonctionnalités, 
comme a été définie par sa spécification. 
– Robustesse :
• Le logiciel réagit correctement dans une situation 
anormale.
– Extensibilité :
E t ibilité
• Le logiciel présente une grande facilité d’adaptation aux 
changements de spécifications
changements de spécifications.

Dr  L BAATI 84
 Les facteurs de qualité d’un logiciel
q g
• Les facteurs de qualité d’un logiciel : 
– Réutilisabilité :
• Les composants du logiciel peuvent très bien servir à la 
construction de nouveaux logiciels.
– Compatibilité :
• Les éléments du logiciel peuvent être combinés à 
d’autres sans problèmes.
– Portabilité : 
P t bilité
• Le logiciel peut être transféré d’un environnement à un 
autre.
autre

Dr  L BAATI 85
 Les facteurs de qualité d’un logiciel
q g
• Les facteurs de qualité d’un logiciel : 
q g
– Efficacité :
• Le
Le logiciel consomme le minimum de ressources tels 
logiciel consomme le minimum de ressources tels
que le temps d’exécution, l’espace mémoire, la bande 
passante du réseau, …etc.
– Facilité d’utilisation :
• Le
Le logiciel présente une grande facilité d
logiciel présente une grande facilité d’utilisation
utilisation 
(installation + apprentissage + pilotage, tous faciles).

Dr  L BAATI 86
 Les outils CASE
Les outils CASE
• CASE : Computer Aided Software Engineering, 
g
ou génie logiciel
g assisté p
par ordinateur :
– Ensemble cohérent d'outils informatiques formant 
un environnement d'aide
un environnement d aide à la conception, au 
à la conception, au
développement et à la mise au point de logiciels 
d'application
d application spécialisés
spécialisés

Dr  L BAATI 87
 Cycle de vie
Approche traditionnelle

L'approche traditionnelle distingue 6 phases dans 
l
la vie du logiciel : 
d l l
– 1. la phase de préanalyse, ou étude d'opportunité; 
p p y pp
– 2. la phase de spécification (software requirements); 
– 3. la phase de conception (software design); 
3 la phase de conception (software design);
– 4. la phase d'implémentation; 
– 5. la phase de test; 
– 6. la phase de maintenance. 
Dr  L BAATI 88
 Cycle de vie
Approche traditionnelle
• La phase de préanalyse
La phase de préanalyse répond à la question pourquoi: 
répond à la question pourquoi:
– pourquoi faut‐il réaliser un certain logiciel, 
– quels sont les besoins?
quels sont les besoins? 
– pourquoi a‐t‐on besoin du logiciel? 
– y a‐t‐il
y a t il de meilleures alternatives? 
de meilleures alternatives?
– le logiciel sera‐t‐il satisfaisant pour les utilisateurs? 
– y
y a‐t‐il un marché pour le logiciel? 
p g
• Ici se pose également la question des ressources nécessaires 
pour réaliser le logiciel (budget, personnel, matériel). La 
réponse de la phase de préanalyse est oui ou non: 
– oui, la décision est prise de réaliser le logiciel; 
– non, le projet est abandonné. 
Dr  L BAATI 89
 Cycle de vie
Approche traditionnelle
• lla phase de spécification
h d é ifi ti (des besoins) défini les 
(d b i ) défi i l
fonctions à réaliser. La phase de spécification répond à 
la question quoi. Si l'on considère un logiciel effectuant 
q q g
le paiement des salaires dans une entreprise, la phase 
de spécification permettra de répondre notamment 
aux questions suivantes:
aux questions suivantes: 
– les employés sont‐ils enregistrés sur bande ou sur disque? 
– q
quel est le format de chaque enregistrement du fichier? 
q g
– quel est le format des sorties? 
– etc. 
• Le résultat de la phase de spécification est le cahier des 
charges du logiciel (spécification des besoins, software 
requirement specification). 
specification)
Dr  L BAATI 90
 Cycle de vie
Approche traditionnelle
• La phase de conception répond à la question; 
g p
comment réaliser le logiciel défini par le CC. 
– Le résultat de cette phase est l'architecture du 
logiciel, autrement dit la décomposition en
logiciel, autrement dit la décomposition en 
modules, avec spécification des interfaces de 
chacun des modules.
chacun des modules. 
– Dans la phase de conception, on s'occupe 
également de définir de manière plus ou moins
également de définir de manière plus ou moins 
détaillée les algorithmes de chacune des procédures 
des modules Ceci est appelé conception détaillée
des modules. Ceci est appelé conception détaillée. 
Dr  L BAATI 91
 Cycle de vie
Approche traditionnelle
• La phase d'implémentation s'occupe du codage 
p
de chacun des modules définis lors de la phase 
de conception. Le résultat de cette phase est le 
code de chacun des modules
code de chacun des modules. 
• La phase de test commence généralement par 
l
le test séparé de chacun des modules et finit 
é é h l f
par le test complet de tout le logiciel. Le 
résultat de cette phase est un logiciel 
opérationnel. 
opérationnel.
Dr  L BAATI 92
 Cycle de vie
Approche traditionnelle
• U
Une fois le logiciel opérationnel, commence
f i l l i i l é ti l l
la 
phase de maintenance. On distingue dans cette 
phase: 
phase:
– la maintenance corrective , qui s'occupe de corriger les 
bugs (c'est‐à‐dire les erreurs) découverts une fois le 
g ( )
logiciel remis au client; 
– la maintenance adaptative qui adapte le logiciel à un 
environnement (logiciel et matériel) qui évolue (par
environnement (logiciel et matériel) qui évolue (par 
exemple adaptation d'un logiciel à une nouvelle version 
d'un système d'exploitation); 
– la maintenance perfective , qui s'occupe d'étendre le 
logiciel pour y inclure de nouvelles possibilités, de 
nouvelles fonctions etc
nouvelles fonctions, etc. 
Dr  L BAATI 93
 Critique approche traditionnelle
Critique approche traditionnelle
• L'enchaînement
L enchaînement laisse supposer qu
laisse supposer qu'une
une fois une phase 
fois une phase
terminée on n'y revient jamais (pour modifier certaines 
décisions). Cette vue est bien trop simpliste pour 
plusieurs raisons:
plusieurs raisons: 
– plus on avance dans le projet, plus on le maîtrise, et donc 
p
plus on a tendance à revenir sur certains choix faits alors 
que l'ensemble du projet était moins bien cerné; 
– lors de la spécification d'un logiciel, certaines 
considérations sur l'implémentation
considérations sur l implémentation peuvent être utiles. A 
peuvent être utiles A
défaut, certains aspects du cahier des charges pourraient 
être irréalistes (il s'agit donc ici de l'anticipation partielle 
d'une
d une phase future); 
phase future);
– certaines spécifications (c'est‐à‐dire certains aspects du 
cahier des charges) peuvent changer en cours de projet, 
parce que le client change d'avis. 
l li t h d' i
Dr  L BAATI 94
 les approches alternatives
• Le cycle de vie du logiciel tel qu'il est présenté offre un 
inconvénient majeur: le retour (feed‐back) de l'utilisateur du 
l i i l
logiciel ne peut intervenir que relativement tard dans le 
ti t i l ti tt dd l
développement (après le codage) :
– prototypage rapide
p yp g p : (rapid
( p p prototyping) Un prototype est à 
yp g) p yp
comprendre ici comme un logiciel n'implémentant que les aspects 
les plus importants du logiciel final et permettant ainsi de tenir 
compte des réactions de l'utilisateur avant de développer le 
produit définitif; 
d i défi i if
– approche "langage de très haut niveau" : Cette approche permet 
de produire rapidement des logiciels ayant de plus peu d'erreurs. 
Les applications de gestion sont un domaine typique où ces 
méthodes semblent particulièrement adaptées; 
– approche "réutilisation" de logiciel : Il s'agit ici de constituer une 
bibliothèque de modules. Lors de la réalisation d'un nouveau 
logiciel, on cherchera le plus possible à utiliser des modules 
existants.  ceci s'applique pas à un domaine relativement neuf.

Dr  L BAATI 95
 Exemple cycle de vie
Cycle de vie d’un projet info (1/4)
La naissance du projet comporte 3 étapes :
– 1) le schéma directeur :
)
= ensemble des intentions de l’entreprise 
planifiées grossièrement sur 1 à 3 ans
planifiées grossièrement sur 1 à 3 ans
– 2) l’avant‐projet :
= étude d’opportunité (intention => projet ?)
é d d’ i é (i i j ?)
Synonymes : étude de faisabilité, étude préalable, pré‐étude
– 3) le projet : son existence est liée à …
f y
… la faisabilité du système à réaliser
Dr  L BAATI 96
Cycle de vie d’un
Cycle de vie d un projet info (2/4)
projet info (2/4)

Dr  L BAATI 97
Cycle de vie d’un
Cycle de vie d un projet info (3/4)
projet info (3/4)

Dr  L BAATI 98
Cycle de vie d’un
Cycle de vie d un projet info (4/4)
projet info (4/4)

Dr  L BAATI 99
 Exemple de découpage pour une 
conduite de projet informatique (1/7)

L’activité de conduite du projet comporte 6 
phases :
h
– Phase 0 : l’étude d’opportunité
– Phase 1 : l’étude initiale de projet
– Phase 2 : l’étude détaillée
– Phase 3 : le pilotage de la réalisation, de la 
recette, et de l’intégration
g
– Phase 4 : la formation
– Phase 5 : le bilan
Phase 5 : le bilan
Dr  L BAATI 100
Les 6 phases de la conduite de projet 
(2/7)
• Phase 1 : l’étude d’opportunité
– à partir de l’ordre de mission (= la demande)
p ( )
– constituer un dossier
• * présentant les besoins fonctionnels, les gains 
présentant les besoins fonctionnels les gains
escomptés, les contraintes, etc.
• * proposant des orientations détaillées
proposant des orientations détaillées
• * à soumettre au comité de validation
– passage à la phase 1 (EIP)  dossier validé
passage à la phase 1 (EIP) dossier validé

Dr  L BAATI 101
Les 6 phases de la conduite de projet 
(3/7)
• Phase 2 : l’étude initiale de projet
– à partir d’un besoin identifié et validé (= la 
p f (
demande)
– constituer un dossier
constituer un dossier
• présentant l’analyse fonctionnelle, les gains affinés, le 
plan d’intégration,
plan d intégration, etc.
etc.
• proposant différents scénarios évalués
• à soumettre au comité de validation
à soumettre au comité de validation
– passage à la phase 2 <==> validation choix du 
scénario
Dr  L BAATI 102
Les 6 phases de la conduite de projet 
(4/7)
• Phase 3 : l’étude détaillée
– à partir d’un scénario retenu et validé (= le contrat)
p ( )
– constituer le dossier d’étude détaillée :
• présentant
présentant ll’analyse
analyse fonctionnelle détaillée, les gains 
fonctionnelle détaillée les gains
affinés, le plan de recette, les charges projet réestimées, 
etc.
• à transmettre aux équipes de réalisation
– passage à la phase 3 <
passage à la phase 3 <==>> livraison du dossier aux 
livraison du dossier aux
équipes de réalisation

Dr  L BAATI 103
 Les 6 phases de la conduite de projet 
(5/7)
• Phase 4 : le pilotage de la réalisation, de la 
g
recette, et de l’intégration
– But : conduire les travaux (savoir faire faire)
– Activités :
Activités :
• contrôler le respect des critères qualité 
qualité de la conduite ≠ qualité du système
lité d l d it ≠ lité d tè
• faire la revue des incidents non résolus
• signer le contrat de service
i l t td i
• assister les utilisateurs du nouveau système
• etc.
Dr  L BAATI 104
 Les 6 phases de la conduite de projet 
(6/7)
Phase 5 : la formation
Ph 5 l f ti
• Le but de cette phase est de …
Le but de cette phase est de
– … former les gestionnaires du nouveau 
système
• gestionnaires techniques :
g q
exploitation, assistance téléphonique …
• gestionnaires métiers :
gestionnaires métiers :
responsables du paramétrage métier …
– … former les utilisateurs du nouveau système
Dr  L BAATI 105
Les 6 phases de la conduite de projet 
(7/7)
Phase 6 : le bilan
• Le but de cette phase est de …
Le but de cette phase est de …
• … tirer un enseignement de l’expérience …
• par rapport aux objectifs du projet :
• * ont
ont‐ils
ils été atteints ? pourquoi ? comment ?
été atteints ? pourquoi ? comment ?
• par rapport à l’organisation du projet :
• * quels termes ont été tenus ? comment ?
… qui sera utile pour les prochains projets.
qui sera utile pour les prochains projets
Dr  L BAATI 106