1
GÉNIE LOGICIEL
ET APPLICATION A LA
QUALITE LOGICIEL
1

2
Au commencement, il y avait …
 programmation individuelle sur de petits problèmes
 algo, langages, structures de données
 (parfois) un peu de méthodologie : analyse descendante
 Ce que vous connaissez : le programme informatique
 Vos compétences :
 Votre vision ? La programmation est excitante et ludique

3
Qu’est-ce qu’un logiciel ?
 il est fait pour des utilisateurs
 il est complexe et de très grande taille
 il fait intervenir plusieurs participants
 il est long et coûteux à développer
 dialoguer métier, produire des documents
homme-mois
nb instructions
 1/2 M Inst.  exp. physique des particules CERN
 1 M Inst.  central téléphonique
 50 M Inst.  contrôle sol + vol navette spatiale
 travail en équipe(s), organisation, planification
 risques nombreux et important : délais, coût

4
Définition du logiciel
Un logiciel (software) est l’ensemble des programmes,
des procédures et des documentations nécessaires au
fonctionnement d’un système informatique

5
Caractéristiques du logiciel - 1
 le logiciel est facile à reproduire
 tout le coût se trouve dans le développement
 le logiciel est immatériel et invisible
 on ne peut l’observer qu’en l’utilisant
 la qualité n’est pas vraiment apparente
 difficile d’estimer l’effort de développement
 développement difficile à automatiser
 beaucoup de main-d’œuvre nécessaire …

6
Caractéristiques du logiciel - 2
 le logiciel ne s’use pas, mais il vieillit
 complexification indue
 duplication de code
 introduction d’erreurs
Détérioration suite aux changements :
Mal conçu au départ :
 inflexibilité
 manque de modularité
 documentation insuffisante
Evolution du matériel

7
Différentes catégories de logiciels
 sur mesure : pour un client spécifique
 générique : vendu sur un marché

8
Différents types de logiciels
 système d’information et d’aide à la décision
 logiciel temps-réel
 logiciel embarqué
 logiciel distribué

9
Problématique historique du logiciel
« D’une part le logiciel n’est pas fiable,
d’autre part il est incroyablement difficile de
réaliser dans les délais prévus des logiciels
satisfaisant leur cahier des charges »

10
Le logiciel n’est pas fiable …
 Quelques exemples célèbres :
 1ère sonde Mariner vers Vénus
 navette spatiale
 ATT
 avion F16
 bug de l’an 2000
 perdue dans l’espace (erreur Fortran)
 lancement retardé (problème logiciel)
 appels longue distance suspendus (changement de version)
 retourné à l’équateur (non prise en compte hémisphère sud)
 Tout système comporte des bugs …

11
Délais et exigences non satisfaits …
 Quelques exemples célèbres :
 OS 360 d’IBM
 aéroport de Denver (système de livraison des bagages)
 SNCF (système Socrate)
 en retard, dépassement mémoire et prix, erreurs
 1 an de retard
 difficultés importantes

12
Abandons …
 Quelques exemples célèbres :
 EDF (contrôle-commande centrales 1400 MWatts)
 bourse de Londres (projet d’informatisation)
 Etats-Unis (système de trafic aérien)
 renonce après plusieurs années d’efforts
 abandon : 4 années de travail + 100 ML perdus
 abandon
 La non rencontre des exigences et les dépassements
de délais sont fréquents : 300 à 400 %

13
Naissance d’une nouvelle discipline
 Problématique apparue dès les années 1960
 Conférence parrainée par l’OTAN (1968)
 Naissance du « Génie Logiciel » (software engineering)
P. Naur, B. Randall (Eds)
Software Engineering : A Report on a Conference
Sponsored by the NATO Science Committee
NATO, 1969
Historique

14
Naissance d’une nouvelle discipline
 Démarche de développement ingénierique
 Principes, méthodes, outils
 Techniques de fabrication assurant :
Objectif
 respect des exigences
 respect de la qualité
 respect des délais et des coûts

15
Définition du « Génie Logiciel »
 la résolution de problèmes posés par un client
 par le développement systématique et l’évolution
 de systèmes logiciels de grande taille et de haute qualité
 en respectant les contraintes de coûts, de temps, et autres
Processus visant :

16
Résolution de problèmes posés par un client …
 identifier et comprendre le problème à résoudre
 solution utile résolvant un problème concret
 la solution peut être de ne rien développer !

17
Développement systématique et évolution …
 techniques maîtrisées, organisation, rigueur
 bonnes pratiques standardisées (IEEE, ISO)
 la plupart des projets consistent en une évolution

18
Systèmes de grande taille et haute qualité …
 travail en équipe(s)
 bonne coordination essentielle
 principal défi : subdiviser et recomposer harmonieusement
 produit final : critères de qualités bien établis

19
Respectant les contraintes …
 les ressources sont limitées (temps, argent, …)
 le bénéfice doit être supérieur aux coûts
 la productivité doit rester concurrentielle
 mauvaise estimation  échec

20
Transition …
 ne pas remplir les exigences du client
 produire un logiciel non fiable
 dépasser les délais, les coûts et autres contraintes
Risques majeurs du développement de logiciels :

21
Méthodes du Génie Logiciel
Méthodologies de développement

22
Introduction
 on décompose la production en « phases »
 l’ensemble des phases constitue un « cycle de vie »
 les phases font apparaître des activités clés
Comme pour tout produit manufacturé complexe :

23
Activités du développement de logiciel
 analyse des besoins
 spécification
 conception
 programmation
 intégration
 vérification et validation

24
Analyse des besoins
 But :
 déterminer ce que doit faire (et ne pas faire) le logiciel
 déterminer les ressources, les contraintes
 Caractéristiques :
 parler métier et non info
 entretiens, questionnaires
 observation de l’existant, étude de situations similaires
 Résultat : ensemble de documents
 rôle du système
 future utilisation
 aspects de l’environnement
 (parfois) un manuel d’utilisation préliminaire

25
Spécification
 But :
 établir une 1ère description du futur système
 consigner dans un document qui fait référence
 Données :
 résultats de l’analyse des besoins + faisabilité informatique
 Résultat : Spécification Technique de Besoin (STB)
 ce que fait le logiciel, mais pas comment
 pas de choix d’implémentation
 (parfois) un manuel de référence préliminaire
 Remarques :

26
Conception
 But :
 décrire comment le logiciel est construit
 décider comment utiliser la techno. pour répondre aux besoins
 Travail :
 enrichir la description de détails d’implémentation
 pour aboutir à une description très proche d’un programme
 2 étapes :
 conception architecturale
 conception détaillée

27
Conception architecturale
 But : décomposer le logiciel en composants
 mettre au point l’architecture du système
 définir les sous-systèmes et leurs interactions
 concevoir les interfaces entre composants
 Résultat :
 description de l’architecture globale du logiciel
 spécification des divers composants

28
Conception détaillée
 But : élaborer les éléments internes de chaque sous-syst.
 Résultat :
 pour chaque composant, description des
 structures de données, algorithmes
 Remarque :
 si la conception est possible, la faisabilité est démontrée
 sinon, la spécification est remise en cause

29
Programmation
 But :
 passer des structures de données et algorithmes
 à un ensemble de programmes
 Résultat :
 ensemble de programmes
 ensemble de bibliothèques / modules
 documentés (commentaires)
 activité la mieux maîtrisée et outillée (parfois automatisée)
 Remarque :

30
Gestion de configurations et Intégration
 Gestion de configurations :
 gérer les composants logiciels (programmes, bibliothèques, …)
 maîtriser leur évolution et leurs mises à jour
 Intégration :
 assembler les composants
 pour obtenir un système exécutable

31
Vérification
 But : vérifier par rapport aux spécifications
 vérifier que les descriptions successives
 (et in fine le logiciel) satisfont la STB
 Moyens : revues de projet, tests
 4 types de tests :
 test unitaire : composants isolés
 test d’intégration : composants assemblés
 test système : système installé sur site
 test d’acceptation : testé par l’utilisateur
 test = chercher des erreurs dans un programme
 exécution sur un sous-ensemble fini de données

32
Validation
 But : vérifier par rapport aux utilisateurs
 Moyen : revues de projet

33
Maintenance
 But :
 corriger des défauts
 améliorer certaines caractéristiques
 suivre les évolutions (besoin, environnement)
 peut remettre en cause les fonctions du système
 peut impliquer un re-développement (re-ingeneering)
 Remarque :

34
Maquettage / Prototypage
 But :
 préciser les besoins et les souhaits des utilisateurs
 développer rapidement une ébauche du système
 2 types de maquettes :
 maquette exploratoire : spécification
 maquette expérimentale : conception

35
Répartition des activités
Actuellement, dans un projet logiciel bien conduit :
40 % Analyse, Spécification, Conception
20 % Programmation
40 % Intégration, Vérification, Validation

36
Résumé
 analyse des besoins
 spécification
 (maquettage)
 conception
 architecturale
 détaillée
 programmation
 config. et intégration
 vérif. et validation
 maintenance
descriptions
de plus en plus
précises
=
raffinements

Exécutable + Doc.

37
Introduction
 Modèle de développement ?
 enchaînements et interactions entre les activités
 But pour le projet : ne pas s’apercevoir des pbs qu’à la fin
 contrôler l’avancement des activités en cours
 vérifier / valider les résultats intermédiaires
 Objectif général : obtenir des processus de développement
 rationnels
 contrôlables
 reproductibles

38
Modèles de développement logiciel
 modèle en cascade (fin des années 1960)
 modèle en V (années 1980)
 modèle en spirale (Boehm, 1988)

39
Modèle en cascade

40
Modèle en cascade
 principe :le développement se divise en étapes
 une étape se termine à une certaine date
 des docs ou prog. sont produits à la fin de chaque étape
 les résultats d’étapes sont soumis à revue
 on passe à l’étape suivante ssi l’examen est satisfaisant
 une étape ne remet en cause que la précédente
 commentaire :
 modèle séduisant car simple
 moyennement réaliste (trop séquentiel)

41
Modèle en V

42
Modèle en V
 principe :les premières étapes préparent les dernières
 interprétation : 2 sortes de dépendances entre étapes
 en V, enchaînement séquentiel (modèle en cascade)
 de gauche à droite, les résultats des étapes de départ
sont utilisés par les étapes d’arrivée
 commentaire :
 avec la décomposition est écrite la recomposition
 vérification objective des spécifications
 modèle plus élaboré et réaliste
 éprouvé pour de grands projets, le plus utilisé

43
Modèle en spirale

44
Modèle en spirale
 principe :développement itératif (prototypes)
 interprétation : chaque mini-cycle se déroule en 4 phases
1. Analyse des besoins, Spécification
2. Analyse des risques, Alternatives, Maquettage
3. Conception et Implémentation de la solution retenue
4. Vérification, Validation, Planification du cycle suivant
 commentaire :
 nouveau : analyse de risques, maquettes, prototypage
 modèle complet, complexe et général
 effort important de mise en œuvre
 utilisé pour projets innovants ou à risques

45
Résumé
 modèles : enchaînements et interactions entre étapes
 passage d’une étape à la suivante :
 documents, tests
 vérifiés et validés
 3 modèles : cascade, V, spirale (séquentiels et itératif)
 cascade : simple mais pas très réaliste
 spirale : nouvelles notions, très complet mais lourd
 V : assez réaliste, le plus éprouvé et utilisé

46
Maturité du processus de développement
 notion définie par le SEI (Software Engineering Institute)
 Capacity Maturity Model (CMM)
 5 niveaux de maturité :
 Initial
 Reproductible
 Défini
 Géré
 Optimisé

47
Niveaux de maturité

48
Etude américaine (1991)
Etude SEI
Organisations américaines

49
Etude américaine (1999)
Etude SEI
Organisations américaines

50
Principes du Génie Logiciel
Vers une assurance qualité …

51
Différentes perceptions de la qualité …
QUALITÉ
EXTERNE
QUALITÉ
INTERNE

52
Facteurs de qualité - 1
 complétude fonctionnelle
 tâches effectuées sans problème
 fonctionne même dans des cas atypiques
 ergonomie / convivialité
 fiabilité / robustesse
 réalise toutes les tâches attendues
 facile d’utilisation
 apprentissage aisé
Qualité externe :

53
Facteurs de qualité - 2
 adaptabilité
Qualité interne :
 le fonctionnement du logiciel est facile à comprendre
 réutilisabilité
 traçabilité / compréhension
 facile à modifier, à faire évoluer
 des parties peuvent être réutilisées facilement
 efficacité / performance
 bonne utilisation des ressources (mémoire, cpu, …)
 portabilité
 capacité à marcher dans un autre contexte ou env.

54
Comment agir sur la qualité logicielle ?
 rigueur et formalisme
 séparation des préoccupations
 modularité
 généralité / abstraction
 incrémentalité
 anticipation des changements
La qualité est atteinte ou améliorée en appliquant
certains principes :

55
Rigueur et formalisme
 rigueur = précision, exactitude (confiance en la fiabilité)
 formalisme = le plus haut degré de rigueur (mathématiques)
 spécification formelle
 vérification formelle (preuve)
 analyse de complexité d’algorithmes
 …
 nécessaire pour les parties critiques (haut risque)
 peut être utilisé dans chaque phase

56
Séparation des préoccupations - 1
 principe : traiter séparément les ≠ aspects d’un problème
 résultat : réduit la quantité de complexité à contrôler
 diviser pour régner

57
Séparation des préoccupations - 2
 domaine de problème : quoi résoudre ?
 domaine de solution : comment résoudre ?
 séparation de domaine
 différentes sortes de séparations :
 séparation de temps : phases du cycle de vie
 séparation de qualité
 vues séparées sur le logiciel : modélisation en UML
 séparation de responsabilités : org. en équipes projet
 maquettes, prototypes
 conception globale, détaillée
 cas d’utilisation, structure statique
 comportement dynamique, architecture

58
Modularité
 principe : séparer le système en composants logiques
 avantages :
 modules
 conçus et construits séparément
 réutilisés
 réduction de complexité
 les modules peuvent être
 système modifié en changeant un nombre limité de modules

59
Généralité / Abstraction
 généraliser un problème particulier
 le rendre réutilisable dans d’autres contextes
 design patterns (modèle de conception):
des solutions généralisées pour des
 logiciel générique vs logiciel sur mesure
 principe :
 exemple :
problèmes typiques de conception

60
Incrémentalité
 développer le logiciel en une série d’incréments
 se rapprocher de la solution par raffinements successifs
 cycle de vie en spirale
 phase de conception
 principe :
 exemple :

61
Anticipation des changements
 réparation des erreurs détectées
 adaptation à de nouveaux environnements
 traitement de nouvelles exigences
 changements dans les exigences
 changement des formats de données
 changement d’exigences non-fonctionnelles
 le logiciel évolue constamment pour différentes raisons :
 avant de développer, poser les questions :
 quels changements, où ?
 comment les rendre plus faciles à appliquer ?

62
Résumé
 qualité externe : client, utilisateurs
 qualité interne : développeurs, gestionnaires
 la qualité du logiciel est fondamentale
 elle est perçue différemment selon les points de vue :
 pour l’atteindre, on adopte des principes
 participation des activités et modèles de développement
 l’utilisation de l’approche OO participe aussi beaucoup
à remplir ces objectifs

63
Résumé général
 logiciel ≠ programme
 problèmes :  pas fiable
 dépassements (délais, coûts)
 non conforme au cahier des charges
 génie logiciel :  démarche ingénierique
 méthodes, principes, outils
 méthodes :  processus de développement
 activités et modèles (cascade, V, spirale)
 principes : pour atteindre des objectifs de qualité
 outils : Ateliers de Génie Logiciel (AGL)

64
Conclusion
 situation en progrès :  logiciel plus fiable
 plus facilement modifiable
 satisfait mieux les utilisateurs
 en contrepartie, les problèmes sont plus critiques,
 centr. téléph., centrales nucléaires
 avions, spatial, ferroviaire
 banque, bourse, …
 plus complexes,
 de plus en plus de fonctionnalités
 systèmes distribués
 mutations technologiques rapides
 et les exigences plus fortes (fiabilité, permanence du service)
 la maîtrise du logiciel reste un défi scientifique et
technologique majeur

65
BIBLIOGRAPHIE
• Normes ISO 2000 V2000- V2008
• Normes ISO 14001
• Cours EPITA Stéphanie CARON
• Cours Polytech Nice, Michel KOENIG
• Assurance qualité normes iso 9000 en pratique , T1997 C. Jambart poche.
Paru en 10/1997
• CNAM
• ECL Valérie CAPRON et Rémi BACHELET