Le document présente une introduction au génie logiciel, soulignant les crises répétées de qualité et de complexité dans le développement de logiciels. Il traite des causes historiques de ces crises, des caractéristiques des logiciels et de leur qualité, ainsi que des pratiques du génie logiciel nécessaires pour y faire face. En conclusion, il souligne l'importance d'une approche systématique et méthodique pour améliorer la conception et la maintenance des logiciels.

1. I
Cours de génie logiciel
n°1
Introduction au génie logiciel
Version 1.2 janvier 2013
Stéphane Salmons
g 6 )  N O 4 Y
1

2. Avertissements/Contact
Violation de copyright / copyright infringement
‣ Si l’utilisation d’une ressource de cette présentation va a l’encontre de sa licence
d’utilisation, cela n’est pas intentionnel. Veuillez contacter l’auteur et la ressource
sera immédiatement retirée.
‣ If the use of a resource of this slideshow conflicts with its licence, this not intentional.
Please contact the author to have the resource immediately removed
Contact
‣ stephane.salmons@gmail.com
2

3. Sommaire
La crise du logiciel
Qu’est-ce qu’un logiciel ?
La Qualité du logiciel
Le génie logiciel
Conclusion
3

4. La crise du logiciel
Naissance et enjeux du génie logiciel
4

5. Les débuts de la crise
Destruction de Mariner 1
(1962)
‣ Cause directe
Le programme de contrôle ne lisse plus
les valeurs de la vitesse et réagit
brutalement à des variations mineures
‣ Impact
Destruction 297s après le décollage
Coût non évalué
‣ Origine
Erreur de transcription d’une formule
dans le code source
5

6. Les débuts de la crise
Trouverez-vous le bug ?
...
IF
(TVAL
.LT.
0.2E-­‐2)
GOTO
40
DO
5
K
=
1,3
DO
40
M
=
1,
3
…
W0
=
(M-­‐1)*0.5
X
=
H*1.74533E-­‐2*W0 5
CONTINUE
DO
20
N0
=
1,
8
EPS
=
5.0*10.0**(N0-­‐7)
CALL
BESJ(X,
0,
B0,
EPS,
IER)
IF
(IER
.EQ.
0)
GOTO
10
20
CONTINUE
DO
5
K
=
1.
3
T(K)
=
W0
Z
=
1.0/(X**2)*B1**2+3.0977E-­‐4*B0**2
D(K)
=
3.076E-­‐2*2.0*(1.0/X*B0*B1+3.0977E-­‐4*
*(B0**2-­‐X*B0*B1))/Z
E(K)
=
H**2*93.2943*W0/SIN(W0)*Z
H
=
D(K)-­‐E(K)
DO5K=1.3
5
CONTINUE
10
CONTINUE
…
Y
=
H/W0-­‐1 5
CONTINUE
40
CONTINUE
...
C’est une autre cause invoquée pour l’accident de Mariner
6

7. Les débuts de la crise
Nombreux autres exemples
(invérifiables)
‣ Convocation de centenaires à l’école
Codage de l'âge sur 2 chiffres
‣ Retournement sur le dos d’un avion au
passage de l’équateur
Changement de signe de la latitude non pris en
compte
‣ Blocage des communications téléphoniques
pendant 9h aux USA
Installation d’un patch non testé
7

8. Réactions à la crise
Comment faire des logiciels de qualité ?
‣ L’OTAN jette les bases du génie logiciel en 1968
8

9. La crise se poursuit ...
Rejet du système Socrate à Destruction d’Ariane 5 Perte de Mars Climate Orbiter
la SNCF -1990 1996 1999
‣ Cause directe ‣ Cause directe ‣ Cause directe
Importantes difficultés de Conversion entier/flottant non autorisée Confusion entre pieds et mètres
déploiement et d’utilisation
‣ Impact ‣ Impact
‣ Impact Explosion 30s après le décollage Destruction de la sonde à l’entrée de
Report de la clientèle vers Une année de retard pour le programme l’atmosphère martienne
d’autres moyens de transport Ariane 5 Coût : 120 millions de $
Coût : non communiqué
‣ Origine ‣ Origine
‣ Origine Reprise du code spécifié pour Ariane 4 Communication défaillante entre
Rachat d’un système développé Absence de tests de validation prévol équipe GB et US
pour une compagnie aérienne Spécifications approximatives
Désactivation de la gestion des exceptions
Conservation de code inutile
9

10. La crise se poursuit ...
Bogue de l’an 2000 Échec du déploiement de PeopleSoft
chez Avis - 2004
‣ Cause directe
Codage de la date sur 2 caractères ‣ Cause directe
Multiples retards de déploiement
‣ Impact
Nombreux surcoûts d’adaptation
Très nombreuses mesures préventives
et correctives ‣ Impact
Coût : estimé à 500 milliards de F Abandon du projet
‣ Origine Coût : 45 millions d’euros (le projet devait
initialement améliorer la profitabilité de
Arbitrage économie mémoire / durée
l’entreprise)
de vie
Mauvaise perception de la durée de vie ‣ Origine
des logiciels Complexité du logiciel mal perçue
Charge d’intégration et d’adaptation sous-estimée
10

11. ... persiste encore aujourd’hui ...
Devenir des projets de développement logiciel
1994 2009
Retard : 63%
Dépassement de budget : 45%
Fonctionnalités absentes : 33%
16%
Le plus souvent : les 3 en même Réussite
temps
32% Annula,on
Echec
par,el
44%
53%
31%
24%
http://www.projectsmart.co.uk/docs/chaos-report.pdf
Peu d’autres industries présentent une telle situation
11

12. ... et devient chronique
The Software Chronic Crisis
‣ “Despite 50 years of progress, the software
industry remains years-perhaps decades-
short of the mature engineering discipline
needed to meet the demands of an
information-age society”
‣ Gibbs, Scient. Am., Sept. 1994
12

13. ... et devient chronique
13

14. ... et devient chronique
14

15. Bilan de la crise
Causes
‣ Incapacité à faire face à la complexité croissante des logiciels
‣ Incompréhension des besoins des utilisateurs
‣ Incapacité à prendre en compte l’évolution des besoins
‣ Absence de pratiques standards ayant fait leur preuves
‣ Absence d’outils pour les mettre en oeuvre
15

16. Bilan de la crise
Conséquences : les logiciels sont ...
‣ Inadaptés aux besoins des utilisateurs
‣ Figés ou très difficiles à faire évoluer
‣ De plus en plus chers à développer
‣ De faible qualité
16

17. Bilan de la crise
Qu’est-ce que la Qualité d’un logiciel ?
Comment faire des logiciels de Qualité ?
17

18. Qu’est-ce qu’un logiciel ?
Caractéristiques d’un concept multiforme
18

19. Les logiciels sont omniprésents
Utilisés par des milliards d’êtres humains chaque jour
Présents dans tous les secteurs de la société
‣ Économie, transports, énergie, santé, recherche, télécommunications,
enseignement, média, arts, ...
Au coeur des systèmes critiques
‣ Centrales nucléaires, trafic aérien, armement, radiothérapie, ...
19

20. Génèse du logiciel
IXe siècle : premier algorithme 1850 : premier programme
‣ Mohammed Al-Khwarizmi, ‣ Ada Lovelace
‣ Calcul des nombres de Bernoulli
‣ Pour la machine analytique de
Charles Babbage (cartes perforées)
Années 1930 : théorie
des programmes
1948 : théorie de
‣ Alan Turing l’information
‣ Concept de Machine de Turing
‣ Décidabilité ‣ Claude Shannon
20

21. Génèse du logiciel
1950 : premier langage de 1956 : premier système d’exploitation
programmation
‣ Robert Patrick (General Motors) et Owen Mock (North
‣ Sir Maurice Wilkes American Aviation)
‣ Microprogrammation en assembleur ‣ GM-NAA I/O fonctionnant sur IBM 104
‣ Concepts de labels, macros,
bibliothèques de sous-routines
1957 : premier langage évolué FORTRAN
‣ John W. Backus et son équipe (IBM)
‣ Vingt fois moins d’instructions que l’assembleur
‣ Concept de boucle
1958 : création du mot “Software”
‣ John Tukey
21

22. Génèse du logiciel
1964 : première définition du 1960 à 1970 : premiers langages orientés objet
génie logiciel ‣ Simula : O.-J. Dahl & K. Nygaard, années 1960
‣ OTAN, Garmish ‣ SmallTalk : A. Kay, 1970
1969 : premier OS moderne
indépendant du hardware
‣ Unix 1985 à 1988 : premier framework applicatif
‣ Ken Thompson et Dennis Ritchie (ATT Bell’s Lab) ‣ MacApp, 1985 (Apple)
‣ Ordonnanceur, gestion de fichiers, ...
‣ Jonhson & Foote, concept de réutilisation 1988
22

23. Qu’est-ce qu’un logiciel ?
Un ensemble constitué de
‣ Programmes
code source (instructions et commentaires)
code exécutable
‣ Données
‣ Documentations
spécifications
dossier de conception
règles de codage
manuel d’utilisation
dossier de test
notice d’installation
...
23

24. Qu’est-ce qu’un logiciel ?
Un produit fabriqué
‣ Par des éditeurs de logiciels
Dans une logique d’offre, pour des utilisateurs génériques (marché)
Les spécifications sont choisies par l’éditeur
Licences commerciales
‣ Par des prestataires en développement (SS2I)
Dans une logique de demande, pour des clients spécifiques
Les spécifications sont choisies par le client
Licences commerciales
‣ Par une communauté de développeurs (open source)
Dans une logique de partage, pour des utilisateurs génériques
Les spécifications sont choisies par les développeurs
Licences libres
24

25. Qu’est-ce qu’un logiciel ?
Une entité se présentant sous trois aspects
d
Comportement
Ces trois aspects
sont largement
Logiciel indépendants
k H
Structures Architecture
25

26. Spécificités du logiciel
Le logiciel est
COMPLEXE
‣ Très grand nombre de constituants élémentaires (instructions ou LoC)
Ex : Windows 7 → 30 MLoC
Ex : Airbus → 5 M de pièces
‣ Grand nombre d’interactions entre instructions
En moyenne, une instruction interagit avec dix autres :
100 kLoC → 100 fois plus d’interactions que 10 kLoC
Le nombre d’états possibles d’un logiciel est gigantesque
26

27. Spécificités du logiciel
Le logiciel est
ABSTRAIT
‣ C’est un produit immatériel (non manufacturé)
‣ Son comportement est difficile à appréhender entièrement
‣ Sa structure est difficile à appréhender entièrement
Le logiciel est beaucoup plus que ce qu’il fait
Le seul plan exact et complet d’un logiciel est le logiciel lui-même
27

28. Spécificités du logiciel
Le logiciel est
MAL DEFINI
‣ Il peut (presque) tout faire
Le logiciel est très peu contraint : ni par des lois physiques, ni par les matériaux, ni par le
processus de fabrication
Les logiciels sont extrêmement variés, il n’y a pas de logiciel “type”
‣ Les besoins sont difficiles à cerner et à formaliser
Le logiciel est abstrait
Utilisateurs et développeurs partagent rarement des connaissances communes
Il est difficile de prévoir tous les usages qui seront fait d’un logiciel
28

29. Spécificités du logiciel
Le logiciel est en
EN CONSTANTE
EVOLUTION
‣ La technologie change rapidement
Plateformes, OS, langages, Frameworks
‣ Les besoins évoluent sans cesse
Pour le client, les changements fonctionnels semblent faciles
‣ La conception est toujours remise en question
La conception est un processus progressif de découverte de ce que le client veut et de comment
cela doit être construit
29

30. Spécificités du logiciel
Le logiciel a une
fabrication atypique
‣ Le premier exemplaire représente tous l’effort de production
‣ La duplication ne coûte (presque) rien
‣ La conception est l’essentiel de la production
Plus proche de l’oeuvre d’art que du produit manufacturé
La qualité du logiciel dépend très fortement de la qualité de la conception
30

31. Spécificités du logiciel
Le logiciel est un domaine de
faible maturite
‣ Pas de théorie prouvée, de pratique faisant consensus
Le génie logiciel est un domaine de recherche actif
‣ Les retours d’expérience sont limités
‣ Le niveau d’industrialisation est (au mieux) celui du fordisme « How Software Engineering can
benefit from traditional industries », T. Sprenger (AdNovum) ICSE 2012 proc. p1000
31

32. Catégories de logiciels
Logiciels Drivers Outils de programmation Logiciels réseau
Système Systèmes d’exploitation Intergiciels (Middlewares) SGBD
Bureautique Progiciels/Métier Temps réel
Applications Jeux Intelligence artificielle Embarqué
Web Logiciels scientifiques Multimédia
Pourriciels Virus, Worms, Trojans Spywares Adwares
32

33. La Qualité du logiciel
Le bon logiciel bien fait
33

34. Qualité logicielle
Norme ISO 9126 (1, 2)
)
Deux types de caractéristiques Qualité
‣ Externes : vues par l’utilisateur du logiciel
‣ Internes : vues par producteur
Ces caractéristiques sont :
‣ Interdépendantes
‣ Complémentaires
‣ Parfois difficilement conciliables
‣ Souvent difficilement mesurables
34

35. Caractéristiques externes
Capacité fonctionnelle
)
‣ Adéquation
Capacité du logiciel à réaliser ce pour quoi il a été prévu (spécifications)
‣ Exactitude
Capacité des fonctionnalités à fournir un comportement exact
‣ Interopérabilité
Capacité du logiciel à fonctionner avec d’autres logiciels (interfaces, protocoles, format de
fichier, etc.)
‣ Sécurité
Capacité du logiciel à protéger ses fonctionnalités, ses données et ses programmes contres
les accès non autorisés
35

36. Caractéristiques externes
Fiabilité
)
‣ Maturité
Fréquence des comportements anormaux
‣ Robustesse (ou tolérance aux pannes)
Capacité du logiciel à réagir correctement (selon spécifications) à des conditions anormales
(hors spécifications)
Les conditions anormales peuvent être d’origine interne ou externe (environnement)
‣ Capacité de récupération
Capacité du logiciel à retourner à un état de fonctionnement normal après une anomalie
Inclu le rétablissement des connexions réseau, la récupération des données, etc.
36

37. Caractéristiques externes
Utilisabilité
)
‣ Facilité d’opération
Effort qu’un opérateur doit fournir pour faire fonctionner le logiciel dans son environnement
‣ Facilité d’apprentissage
Effort qu’un utilisateur doit fournir pour apprendre à réaliser ses tâches avec le logiciel
Dépend de l'audience prévue, du profil des utilisateurs (expert, novice, etc.)
‣ Facilité de compréhension
Effort à fournir pour se représenter les concepts logiques des fonctionnalités du logiciel
‣ Pouvoir d’attraction
Envie suscitée par le logiciel
37

38. Caractéristiques externes
Efficacité
)
‣ Performance temporelle
Temps de réponse entre l’invocation d’une fonctionnalité et sa réalisation
Temps de réalisation de la fonctionnalité
‣ Économie de ressources (nécessaires pour accomplir les tâches prévues)
Puissance CPU
Mémoire
Volume disque
Débit réseau
Puissance électrique
...
38

39. Caractéristiques internes
Maintenabilité
)
‣ Flexibilité (ou modifiabilité ou extensibilité)
Effort à fournir pour modifier le logiciel (pour répondre à une évolution des spécifications ou pour
corriger une anomalie)
‣ Facilité d’analyse
Effort à fournir pour analyser la cause d’une anomalie (à partir des symptômes)
Effort à fournir pour identifier une partie à modifier (à partir d’une évolution de spécification)
‣ Stabilité
Sensibilité du logiciel à un changement effectué dans une de ses parties (effet de bord)
‣ Testabilité
Effort à fournir pour tester le logiciel (préparation des données, des procédures de tests, etc.)
39

40. Caractéristiques internes
Portabilité
)
‣ Adaptabilité
Capacité du logiciel à s’adapter à un changement d’environnement (plateforme matérielle, OS,
compilateurs, etc.)
‣ Facilité d’installation
Effort à fournir pour installer et désinstaller le logiciel
‣ Facilité de migration (ou remplaçabilité)
Capacité du logiciel à remplacer un autre logiciel remplissant des fonctions similaires
40

41. Caractéristiques internes
Réutilisabilité
)
‣ Capacité des parties du logiciel à être utilisées dans le développement d’un autre
41

42. Qualité logicielle
Et la documentation ?
‣ Elle est intégrée dans la plupart des caractéristiques précédentes
42

43. Qualité logicielle
Qualité, coûts et délais sont étroitement liés
Qualité
Coût
Délai
Symboliquement : Qualité = Coûts + Délai
43

44. Le génie logiciel
L’ingénierie au service du logiciel
44

45. Qu’est-ce que l'ingénierie ?
J Outils
R
Standards
Normes U Méthodologies G
Éthique
 ù Méthodes
Mesures
n Principes de bases 
Savoir
 académique
Bonnes
pratiques
45

46. Apports du génie industriel
Grandes étapes de l’industrialisation de la production
manufacturière
‣ Division du travail en tâches ‣ Contrôle Qualité
‣ Mécanisation ‣ Chemin critique
‣ Division des produits en ‣ Qualité totale
sous-ensembles ‣ Production en flux tendu
‣ Automatisation ‣ ...
‣ Standardisation
‣ Interchangeabilité des sous-
ensembles
Une source d’inspiration pour le génie logiciel (et réciproquement)
46

47. Qu’est-ce que le génie logiciel ?
‣ La discipline d’ingénieur qui concerne la production de logiciel sous tous ses aspects
‣ L’étude des pratiques systématiques qui permettent d’obtenir des logiciels
correspondant aux attentes
fiables
avec les performances attendues
respectant les délais et les coûts de construction et de maintenance (Wikipédia)
‣ (1) Une approche systématique, méthodique et quantifiable appliquée au développement,
à l’exploitation et à la maintenance des logiciels ; c’est-à-dire l’application de l’ingénierie
au logiciel
(2) L’étude des approches ci-dessus (IEEE)
De nombreuses autres définitions existent
47

48. Qu’est-ce que le génie logiciel ?
L’art et la manière de bien
créer le bon logiciel
Le bon logiciel répond aux critère de qualité vues de l’utilisateur
Le logiciel bien fait répond aux critères de qualité vues du producteur
48

49. Génie logiciel ou ingénierie logicielle ?
Deux expressions qui signifient la même chose
Occurrences des expressions dans les livres (source : http://books.google.com/ngrams)
49

50. Positionnement dans l’informatique
Ingénierie des télécommunications
Ingénierie logicielle Développement Programmation
Informatique
Ingénierie du hardware
Informatique théorique
50

51. Domaines connexes
G
Gestion de
projet
M
Management
✈
Domaines
métier
Ingénierie
logicielle
= #
Psychologie
Économie
51

52. Activités fondamentales
Analyse Réalisation
Des besoins aux spécifications Des spécifications aux programmes
Clients et ingénieurs définissent le logiciel Les ingénieurs conçoivent et
et son mode opératoire programment le logiciel
Tests Distribution - Maintenance -
Des programmes au produit Évolution
Les ingénieurs et les clients contrôlent Les ingénieurs adaptent le logiciel aux
que le logiciel correspond aux besoins évolutions des clients/du marché
52

53. Les huit principes du génie logiciel
Utiliser les processus
g appropriés N Maîtriser les changements
6 Se soucier de l’utilisateur O Tester sans relâche
) Concevoir pour la Qualité 4 Mesurer la Qualité
Documenter avec
 Maîtriser les dépendances Y discernement
53

54. Les huit principes du génie logiciel
g 6
Utiliser les processus Se soucier de l’utilisateur
appropriés ‣ Comprendre et gérer les besoins
‣ Développer en suivant un ‣ Aider l’utilisateur à exprimer ses
processus standard besoins
‣ Bien compris par l’équipe ‣ Utiliser le vocabulaire de
‣ Adaptés l’utilisateur
à l’organisation du projet ‣ Prévoir que ces besoins
à l’équipe projet évolueront
au type de logiciel
‣ Intégrer l’utilisateur dans le
être pragmatique processus de développement
‣ Incarnés dans des outils 54

55. Les huit principes du génie logiciel
) 
Concevoir pour la Qualité Maîtriser les dépendances
‣ Définir et hiérarchiser les ‣ Identifier les dépendances
objectifs de la Qualité Envers tous les prérequis
‣ Utiliser les styles architecturaux Entre tous les éléments internes
et les patrons de conception Considérer la granularité
adaptés à ces objectifs ‣ Réduire les dépendances
‣ Prévoir et évaluer différentes Maximiser la cohésion
solutions de conception Minimiser le couplage
‣ Utiliser les bonnes pratiques de ‣ Gérer en configuration les
conception - Éviter les “trucs” références des dépendances
‣ Réutiliser au maximum 55

56. Les huit principes du génie logiciel
N O
Maîtriser les changements Tester sans relâche
‣ Choisir un processus de ‣ Tester le plus souvent et le plus
développement adapté à la complètement possible
souplesse voulue (automatisation)
‣ Identifier et tracer l’évolution ‣ Tester en relation avec les
Des besoins exigences
Des décisions d’architecture et de ‣ Tester à différents niveau de
conception granularité
Des sources
‣ Le testeur ne doit pas être un
Des tests développeur
56

57. Les huit principes du génie logiciel
4 Y
Mesurer la Qualité Documenter avec
‣ Par l’analyse technique discernement
analyse statique des sources ‣ Les trois aspects du logiciel
analyse dynamique des comportements
exécutables structures
‣ Par l’évaluation des processus architecture
fréquence des versions, ... ‣ Les tests du logiciel
‣ Par les retours d’utilisations ‣ Ni trop, ni trop peu
nombre de bogues, satisfaction, ...
57

58. Des mythes parfois tenaces
‣ Si on ajoute plus de programmeurs, on pourra rattraper notre retard

‣ Si on sous-traite une partie, on pourra se reposer un peu
‣ Les besoins des utilisateurs changent mais ce n’est pas grave car notre logiciel est flexible
‣ Plus un logiciel a de fonctionnalités, meilleur il est
‣ La qualité d’un logiciel se mesure au nombre de ses bugs
‣ Une fois qu’on a écrit le programme et qu’il fonctionne, le travail est fini
‣ Tant qu’on ne fait pas tourner le programme, on ne peut pas évaluer sa qualité
‣ Si on fait tout ce que le génie logiciel demande, on va perdre du temps et de l’argent
‣ Nos programmeurs ont les meilleurs outils de développement logiciel : nous leur avons
fournis des ordinateurs dernier cri
58

59. Conclusion
59

60. Un domaine en plein essors
Discipline jeune
‣ Premières formations diplomantes aux USA fin des années 1990
Objet d’une R&D très active
‣ Approche à la fois académique et empirique
‣ Une dizaine de journaux et de conférence exclusivement dédiés
‣ Quelques acteurs majeurs :
60

61. Un domaine en plein essors
Quelques référentiels
‣ SWEBOK : Software Engineering Body of Knoledge
‣ CMM : Capability Maturity Model
‣ ISO 12207 : Processus de développement logiciel
‣ ISO 9126 : Qualité logicielle
‣ COCOMO 2 : modèle d’estimation des coûts
‣ ATAM : Architecture Tradeoff Analysis Method
61

62. Un dernier mot
Prendre garde aux (trop) bonnes intentions ...
62

63. Références
63

64. Sources
Sources :
http://fr.wikipedia.org/wiki/ Sources :
ESA Inquiry Board. ARIANE 5: Flight 501 Sources :
Mariner_1
failure. Technical report, European Space http://fr.wikipedia.org/wiki/
http://nssdc.gsfc.nasa.gov/nmc/ Agency, July 1996. Mars_Climate_Orbiter#Perte_de_la_sonde
masterCatalog.do?sc=MARIN1 http://www.esrin.esa.it/htdocs/tidc/ http://www.nirgal.net/mco_end.html
Press/Press96/ariane5rep.html.
http://www.inria.fr/actualites/
inedit/inedit14_evea.fr.html
DO5K=1.3
…
5
CONTINUE
Sources : Sources :
http:// Sources :
http://fr.wikipedia.org/wiki/Mariner_1 http://www.cs.tau.ac.il/
www.lemondeinformatique.fr/
~nachumd/horror.html  http://www.time.com/time/magazine/
actualites/lire-­‐trop-­‐cher-­‐trop-­‐ http://www-­‐aix.gsi.de/~giese/swr/
article/0,9171,969266,00.html
mariner1.html
complique-­‐avis-­‐europe-­‐congedie-­‐  http://users.csc.calpoly.edu/
peoplesoft-­‐et-­‐atos-­‐10462.html http://nssdc.gsfc.nasa.gov/nmc/
~jdalbey/SWE/Papers/att_collapse.html
masterCatalog.do?sc=MARIN1
http://www.baselinemag.com/c/a/  http://www.mit.edu/hacker/part1.html
ERP/Five-­‐ERP-­‐Disasters-­‐
Explained-­‐878312/
64