Introduction

- La place des logiciels dans les systèmes complexes augmente

régulièrement, or, les producteurs de logiciels ne respectent que
rarement les coûts ou les délais de développement.

- Le génie logiciel est l'art de spécifier, de concevoir, de réaliser, et

de faire évoluer ; avec des moyens et dans des délais raisonnables :
des programmes, des documentations et des procédures de qualité.

Critère CQFD : Coût, Qualité, Fonctionnalité, Délai.

 Qu'est-ce qu'un 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.
- La frontière d'un système est le critère d'appartenance au
système.
- L'environnement 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 :
• sa dimension, qu nécessite la collaboration de plusieurs personnes
pour sa réalisation ;
• son évolutivité.
Exemple
une fourmilière, l'économie mondiale, le noyau Linux, . . .
 Qu'est-ce qu'un logiciel ?
- Un logiciel est un ensemble d'entités nécessaires au
fonctionnement d'un processus de traitement automatique de
l'information.

Parm ces entités, on trouve par exemple :

- des programmes (en format code source ou exécutables) ;
- des documentations d'utilisation ;
- des informations de configuration ;
...
 Qu'est-ce qu'un logiciel ?
- Un logiciel est en général un sous-système d'un système
englobant.
- Il peut interagir avec des clients, qu 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 qu régissent ses interactions avec son
environnement.
 Qu'est-ce qu'un logiciel ?
- Le génie logiciel vise à garantir que :
1- La spécification répond aux besoins réels de ses clients ;
2- Le logiciel respecte sa spécification ;
3- Les coûts alloués pour sa réalisation sont respectés ;
4- Les délais de réalisation sont respectés.
5- La qualité correspond au contrat de service initial.
 Les spécificités du logiciel
- une modification infime peut avoir des conséquences critiques ;
- les progrès technologiques très rapides peuvent rendre un
logiciel caduque ;
- il est difficile de raisonner sur des programmes ;
- les domaines des entrées des logiciels sont trop grands 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 ;
- courte durée de vie du matériel,
- beaucoup de méthodes et de langages
- évolution des outils de développement,…
 Principes et techniques
Le GL repose sur un ensemble de principes mis en œuvre par des
méthodes, des techniques et des outils.
• Généralisation : regroupement d'un ensemble de fonctionnalités
semblables en une fonctionnalité paramétrable (généricité,
héritage)
• Structuration : façon de décomposer un logiciel (utilisation
d'une méthode bottom-up ou top-down)
• Abstraction : mécanisme qu permet de présenter un contexte en
exprimant les éléments pertinents et en omettant ceux qu ne le sont
pas
•Documentation : gestion des documents incluant leur
identification, acquisition, production, stockage et distribution
 Principes et techniques
• Modularité :
-Décomposition d'un logiciel en composants discrets
-Le principe est de remplacer le problème initial par des modules
de moindre complexité
-Chaque module traite une partie du problème
-Ils sont compréhensibles, homogènes, indépendants
-Les modules sont reliés entre eux
• Séparation des préoccupations: Le principe est de se concentrer
sur un seul aspect du problème à la fois et le traiter de façon
indépendante
• La construction incrémentale
-Un développement logiciel a plus de chances d'aboutir s il suit un
cheminement incrémental.
 Principes et techniques
•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).
•La décomposition des problèmes en sous problèmes:
- Décorréler les problèmes pour n'en traiter qu'un seul à la
fois.
- Simplifier les problèmes (temporairement) pour aborder leur
complexité progressivement.
 Principes et techniques
•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.
 Principes et techniques
• 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.
• Vérification : détermination du respect des spéciations établies
sur la base des besoins identifiés dans la phase précédente du cycle
de vie
• Documentation : gestion des documents incluant leur
identification, acquisition, production, stockage et distribution
 Qualité du logiciel
• La qualité du logiciel est une notion multiforme qu 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,
– la réutilisabilité : aptitude d'un logiciel à être réutilisé en tout ou
partie,
– la compatibilité : aptitude des logiciels à pouvoir être combinés les
uns aux autres,
 Qualité du logiciel
– 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,
– 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.
 Comment fabriquer un logiciel de
qualité ?
- En plus du respect (essentiel) de sa spécification, la qualité d'un
logiciel dépend des 4 critères suivants :
• Maintenabilité Peut-on faire évoluer le logiciel ? 1
• Robustesse Le logiciel est-il sujet à des dysfonctionnements ?
• Efficacité Le logiciel fait-il bon usage de ses ressources ?
• Utilisabilité Est-il facile à utiliser ?
.
1. Un logiciel ne s'use pas. La correction d'une erreur n'est pas évolution mais un échec
du concepteur.
 Comment fabriquer un logiciel de
qualité ?
- On a essayé d'appliquer les méthodes connues de l'ingénieur
au domaine du logiciel, pour établir des
méthodes fiables sur lesquelles construire une industrie du logiciel.
- Il s'agit de se donner un cadre rigoureux pour :
1 Guider le développement du logiciel, de sa conception à sa
livraison.
2 Contrôler les coûts, évaluer les risques et respecter les délais.
3 Établir des critères d'évaluation de la qualité d'un logiciel.
 Comment fabriquer un logiciel de
qualité ?
- Le génie logiciel est un domaine en pleine évolution qu offre
une grande palette d'outils et de méthodes pour parvenir à
construire du logiciel de qualité.
- Aucune de ces méthodes ne s'est imposée à ce jour : il faut donc
prendre du recul sur les concepts et les conseils qu'elles préconisent
et utiliser son bon sens pour les adapter à chaque situation.
- Ces méthodes se distinguent principalement par :
• leur degré de formalisme ;
• leur champ d'application ;
• les contraintes de qualité qu'elles ambitionnent.
 Qualité du logiciel — approches
formelles
- 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.
Exemple (approches formelles)
• Méthodes : méthode B, model-checking, logique de Hoare, . . .
• Outils et notations : Coq, Z, Atelier B, Why, Frama-C, . . .
• Ces méthodes sont utilisées pour développer des logiciels
critiques.
• Elles correspondent au niveau le plus élevé de certification.
e.g. applications de la méthode B pour développer le logiciel
embarqué des lignes de métro 14 (1998) et 1 à Paris
 Qualité du logiciel — approches semi-
formelles
- 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.
• Bien que ces approches précisent le discours du concepteur s on
le compare à celu décrit à l'aide du langage naturel, elles
contiennent certaines ambiguïtés et n'offrent aucune garantie sur la
qualité des résultats.
- Exemple (approches semi-formelles)
• Méthodes : Rationale Unified Process, Merise, . . .
• Outils et notations : UML, AnalyseSI, . . .
Ces méthodes sont utilisées aujourd'hu par l'industrie du logiciel.
 Qualité du logiciel — approches
empiriques
- Les approches empiriques mettent en avant un ensemble de
“bonnes pratiques” qu ont fait leur preuve par l'expérience.
Exemple (approches empiriques)
• Méthodes : unit testing (p.ex. la famille xUnit), peer review,
relecture de code, extreme programming, programmation
défensive, . . .
• Outils : plates-formes de test, Gerrit, gestionnaire de versions
(p.ex. Git), outil de documentation automatique (p.ex. Doxygen) /
literate programming, . . .
 Le processus de développement
Le processus de développement industriel peut être décomposé en
trois grandes activités :
1. Le processus technique :
- Il modélise la procédure à suivre pour réaliser le produit.
- Il est décrit par le cycle de vie que l'on choisit. La prévision est
réalisée par l'analyse des besoins, le suiv par les différents
choix de conception et d'implantation, et l'analyse par les tests
de validations effectués pour voir s le résultat obtenu est bien
conforme aux besoins exprimés.
 Le processus de développement
2. Le processus de gestion :
- il modélise la procédure à suivre pour contrôler les délais et les
coûts.
- commence par une estimation des durées, coûts et efforts
humains nécessaires à la réalisation de chacune des activités
décrites par le cycle de vie. Des mesures d'avancement
permettent d'effectuer le suiv et le contrôle du déroulement du
projet afin d'anticiper d'éventuels écarts et agir au plus tôt pour
corriger la situation. L'analyse des données collectées doit
assurer une amélioration du processus d'estimation et de suiv
pour les projets à venir.
 Le processus de développement
3. Le processus qualité :
- Il modélise la procédure à suivre pour garantir la qualité du
produit, mais aussi des différents processus participant au
développement du produit (gestion et qualité).
- Il a une triple utilité (une par processus) ; il assure au produit
un niveau de qualité défini, il garantit que le processus de
gestion est réalisé comme prévu et enfin, réflexivement, il
assure que le processus qualité s'effectue correctement.
 Cycles de vie d'un logiciel
•Phases : Le cycle de vie du logiciel modélise l'enchaînement des
différentes activités du processus technique de développement du
logiciel.
Tous les modèles différencient 4 grandes activités qu vont, selon le
modèle, interagir différemment. Ce sont :
- Analyse / spécification du logiciel : comprendre le problème, les
besoins, définir ses fonctionnalités et leurs contraintes.
-Conception / implémentation : trouver une architecture pour
résoudre le problème, réaliser le logiciel en conformité avec sa
spécification.
- Validation: s'assure effectivement du respect de la spécification
par le logiciel produit.
- Evolution: adapte le logiciel aux besoins futurs de ses clients.
 Cycles de vie d'un logiciel

• Activités: Le développement du logiciel peut être découpé en

plusieurs activités qu seront présentées brièvement :
- La gestion des exigences, La spécification, La conception,
L'implantation, La validation, L'intégration, Le déploiement, La
maintenance…
Elles fournissent différents produits logiciels (documents,
modèles, code, …)
•Activités permanentes: Il existe également des activités
permanentes
- La documentation, La gestion de projet, La gestion de la qualité,
La gestion de la sous-traitance, etc.
 Cycles de vie d'un logiciel
• Activités:
- Analyse des besoins : Identifier ce que veut le client et les
contraintes, Eviter de produire un logiciel non adéquat.
- Spécification globale : Etablir une première description du futur
système, pour produire une description de ce que doit faire le
système mais sans préciser comment il le fait .
 Cycles de vie d'un logiciel
-Conception architecturale et détaillée : Enrichir la description du
logiciel de détails d'implémentation afin d'aboutir à une description
très proche d'un programme (décrire le comment).
La conception architecturale (ou conception globale) a pour but
de décomposer le logiciel en composants plus simples, définis par
leurs interfaces et leurs fonctions (les services qu'ils rendent). La
conception détaillée fournit pour chaque composant une
description de la manière dont les fonctions ou les services sont
réalisés : algorithmes, représentation des données.
 Cycles de vie d'un logiciel
- Programmation : réalisation, à partir de la conception détaillée,
d'un ensemble de programme ou de composants de programmes .
- Gestion de configurations et intégration: La gestion de
configurations a pour but de maîtriser l'évolution et la mise à jour
des composants tout au long du processus de développement.
L'intégration a pour but de réaliser un ou plusieurs systèmes
exécutables à partir des composants.
 Cycles de vie d'un logiciel
- Validation et vérification :
La validation a pour but de répondre à la délicate question : a-t-
on décrit le bon système, celu qu répond à l'attente des utilisateurs.
La vérification répond à la question : le développement est-il
correct par rapport à la spécification globale ? Ce qu consiste à
s'assurer que les description successives et le logiciel lui-même
satisfont la spécification globale.
 Cycles de vie d'un logiciel
- Intégration et déploiement
Combiner les modules et vérifier le produit dans son ensemble
Le déploiement correspond à l'installation du produit fin chez
le client.
- Maintenance
Il s'agit d'apporter des modifications à un logiciel existant
C'est la phase la plus coûteuse (70% du coût total)
Types
Maintenance corrective, Maintenance prédictive, Maintenance
évolutive.
Cycles de vie d'un logiciel
Projet abandonné

Non

Pourquoi ? Pré analyse

Oui

Quoi? Spécification

Cahier des charges

Comment? Conception
Combien / Quand ?
Découpage du logiciel en modules

Quel? Implémentation

Code

Test

Logiciel
opérationnel
Maintenance
 Schéma général d'un processus de
développement
• Il est très rare d'appliquer un processus comme une unique
séquence des 4 activités précédentes.
• En effet, ce serait à l'encontre du principe d'incrémentalité.
• En général, un logiciel complet est le fruit de plusieurs itérations.
• Chaque itération contient les 4 activités de spécification,
conception, validation et évolution.
• Il existe différents modèles de processus qu organisent de façon
différentes ces activités : le modèle en cascade, le modèle de
développement évolutif, le modèle de développement par
composants,
 Modèle en cascade

• Chaque phase doit se terminer pour commencer la suivante.

• Des documents sont produits pour concrétiser la réalisation de
chaque phase.
 Modèle en cascade — caractéristiques
• Ce modèle très simple présente un développement très linéaire
bien que des retour arrière soient prévus lorsque des erreurs ou des
manques sont détectés.
•La production de documents entre chaque phase améliore le suiv
du projet.
• Lorsqu'une erreur a été commise dans une phase et qu'elle est
détectée dans une phase suivante, il faut faire remonter cette
information dans la phase incriminée et recommencer le processus
à partir de celle-ci. On doit alors reproduire de nouveaux
documents . . .
• Ce modèle de processus impose donc une importante réflexion
sur les choix faits en amont car le coût de la correction d'une
erreur est important.
Modèle en cascade

validation

vérification

test d'intégration et test d'acceptation

test du système
 Modèle en cascade — critiques
• Le modèle en cascade rend coûteux le développement itératif
puisque la rédaction des documents de validation de chaque phase
demande beaucoup de travail.
• Ce modèle est inadapté au développement de systèmes dont la
spécification est difficile à formuler a priori.
- Typique d'un développement industriel pour lequel les coûts de
la construction du produit sont trop importants pour se
permettre une erreur de choix de conception.
 Modèle de développement évolutif /
par prototype

• Ces trois activités 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èle de développement évolutif —
caractéristiques
• Ce modèle augmente les chances de répondre aux besoins de
l'utilisateur car il permet de les comprendre plus rapidement.
Are we building the right product ?
• Il remplit le critère d'incrémentalité.
• Ce modèle ne dispense d'écrire la spécification du système car il
faut s'assurer que l'implémentation est correct.
Are we building the product right ?
• C'est un processus particulièrement adapté aux projets de taille
moyenne (inférieur à 100 000 lignes de code) comme par exemple
des grosses applications Web ou encore les solutions intégrées pour
les petites entreprises.
 Modèle de développement évolutif —
critiques
• Il est plus difficile de gérer un projet utilisant ce modèle car la
visibilité de l'avancement du développement est peu clair.
• Il est plus difficile de structurer correctement le logiciel
(définir de bonnes abstractions, modulariser efficacement) car les
prototypes sont par définition des produits “bricolés”.
• Le coût en termes de tests et de validation du produit final
peuvent être très importants.
- Des approches mixtes intégrant modèle de développement
évolutif pour produire un premier prototype validé et un
modèle en cascade pour reconstruire correctement un produit
final constituent en général de bons compromis.
 Modèle de développement à livraison incrémentale

Une approche à mi-chemin entre les modèles cascade et évolutif

s'appuie sur une livraison incrémentale du produit.
• Concevoir et livrer au client un sous-ensemble minimal et
fonctionnel du système.
• On hiérarchise les besoins du client en termes de priorité.
• Chaque itération du modèle vise à obtenir un ensemble de
fonctionnalités par ordre de priorité.
• Traiter les parties les plus critiques du système en premier
minimise les risques d'inadéquation avec le produit final.
 Modèle de développement à livraison incrémentale
Critique
• Il se peut que les choix pris en amont, trop focalisés sur ce noyau
de fonctionnalités, compromettent le développement des
fonctionnalités secondaires.
Modèle de développement par
composants
 Modèle de développement par
composants — caractéristiques
• Ce modèle 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.
• Ce modèle permet d'obtenir rapidement des produits de bonne
qualité puisqu'ils sont construits à partir de composants qu 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èle de développement par
composants — critiques
• 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èle de développement en V

• Le principe de ce modèle est qu'avec toute décomposition doit

être décrite la recomposition, et que toute description d'un
composant est accompagnée de tests qu permettront de s'assurer
qu'il correspond à sa description
 Le modèle en Spirale de Boehm
• ce modèle est beaucoup plus général que le précédent. Il met
l'accent sur l'activité d'analyse des risques : chaque cycle de la
spirale se déroule en quatre phases:
1. détermination, à partir des résultats des cycles précédents
--ou de l'analyse préliminaire des besoins, des objectifs du
cycle, des alternatives pour les atteindre et des contraintes ;
2. analyse des risques, évaluation des alternatives et,
éventuellement maquettage ;
3. développement et vérification de la solution retenue, un
modèle « classique » (cascade ou en V) peut être utilisé ic .
4. revue des résultats et vérification du cycle suivant.
Le modèle en Spirale de Boehm
Evaluer les alternatives;
Déterminer Identifier et résoudre les
Les objectifs, Analye risques
Les alternatives Des risques
et les contraintes Analye
Des risques
Analye
Des risques
Analye Prototype
des risques Prot Protopérationnel
Revue prototype1 2 3
Planification Simulation, modèles et
Des besoins et Concept Tests de performance

Du cycle de vieDe l’opération oin

s
Bes ciels n Conception
Plan de i ti o détaillée
Validation log c ep uit
n d
développement Des besoins Co pro code
D u Test
Plan de test et unitaire
Test
D’intégration Test D’intégration
Mise en
service
D’acceptation Développer
Planification de la Et vérifier le produit
Prochaine phase De prochain niveau
 Le modèle en Spirale de Boehm

• Un modèle mixte
• A chaque cycle, recommencer :
1. Consultation du client
2. Analyse des risques
3. Conception
4. Implémentation
5. Tests
6. Planification du prochain cycle
La gestion de projet