Jjj

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

2. 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. 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. 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. 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. 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. 7
Différentes catégories de logiciels
 sur mesure : pour un client spécifique
 générique : vendu sur un marché

8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 21
Méthodes du Génie Logiciel
Méthodologies de développement

22. 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. 23
Activités du développement de logiciel
 analyse des besoins
 spécification
 conception
 programmation
 intégration
 vérification et validation

24. 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. 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. 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. 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. 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. 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. 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. 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. 32
Validation
 But : vérifier par rapport aux utilisateurs
 Moyen : revues de projet

33. 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. 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. 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. 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. 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. 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. 39
Modèle en cascade

40. 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. 41
Modèle en V

42. 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. 43
Modèle en spirale

44. 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. 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. 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. 47
Niveaux de maturité

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

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

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

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

52. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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