La qualité du logiciel

Introduction au génie logiciel.

 

 

Tous les logiciels ne fonctionnent pas à la perfection

Le Roi des Belges, Philippe, reçoit des dizaines d'amendes pour excès de vitesse en France

Mars 2014 - Seule la BMW du Roi est verbalisée, pas les véhicules de son escorte. Il s'agissait d'un problème informatique de la part de la police française, leur système informatisé n'avait pas intégré les nouvelles plaques d'immatriculation belges, pourtant introduites depuis novembre 2010. Le logiciel ne retient que le premier signe de l'immatriculation, le 1, sans encoder les six lettres et chiffres qui suivent. Le procès-verbal arrive alors au titulaire de la plaque belge immatriculée 1, le Roi. Les véritables contrevenants échappent à la sanction. La France s'est platement excusée...

La gestion comptable de l'Etat en panne...

Chorus, le pharaonique logiciel de refonte de la gestion comptable de l'Etat sur les principes de la LOLF, basé sur SAP, n'est toujours pas pleinement opérationnel.
Coût total 2006-2015 : 1,1 milliard d'euros.

La com de la France ratée au plus haut niveau ...

Le site France.fr est tombé en panne dès son lancement officiel le 14 juillet 2010. Ce prestigieux "portail de la France", a été présenté comme un point d'entrée en cinq langues à destination des touristes, investisseurs étrangers ou expatriés, et doit proposer également des liens vers différents services publics. La faute invoquée par le SIG, "une trop forte fréquentation sur le site, avec 25 000 connexions", a fait rire et fait penser à de incompétence. 4M€

Amazon vend un livre 23,7 millions de dollars

18 avril 2011. Amazon permet aux tiers qui vendent des biens via sa plateforme commerciale de fixer leurs prix grâce à des algorithmes de fixation de prix qui prennent en compte les sommes que demandent d'autres vendeurs pour le même article. Le livre "The Making of a Fly" a été vistime d'une spirale infernale de ces algorithmes entre deux vendeurs. L'un a paramétré pour que son livre soit 0.9983 fois moins cher que le même vendu par son concurrent, l'autre a élevé son prix à 1.270589 fois le prix le plus haut. Les algorithmes ont agit en boucle...
http://www.amelys-info.com/blog/le-livre-qui-valait-23-millions-de-dollars/

Une bête panne de site web...

L'accès aux réservations et achats de billets de train sur le site internet voyages-sncf.com a été fermé plusieurs heures le 20 novembre 2008, à la suite de la mise en ligne d'"une nouvelle version du site". Le site avait déjà connu une longue panne fin juillet qui avait rendu les achats, réservations et impressions de billets impossibles pendant plus de trente heures et la SNCF avait promis d'en "tirer les enseignements". Voyages-sncf.com, premier site de commerce électronique en France, reçoit 700.000 visites par jour et 38 millions de billets y ont été vendus en 2007, soit le quart des tickets SNCF.

 

La non qualité des systèmes informatiques a des conséquences qui peuvent être très graves

08/2014 Perte des deux premiers satellites Galileo de la phase opérationnelle, installés sur une mauvaise orbite. Le lanceur Soyouz a très bien fonctionné, a fonctionné en pleine conformité avec le logiciel embarqué, mais le logiciel était bugué. Coût du bug : 200 M€, + un retard de plusieurs mois dans la finalisation du projets chiffré en dizaines de millions d'euros + un coût énorme en terme d'image...

11/2012 L'US Air Force abondonne son projet d'ERP - Oracle suite à un dépassement de budget de plus d'1 milliard de dollars : le projet visait à remplacer 200 systèmes informatiques métier par un système unifié autour d'un ERP, le chantier avait débuté en 2005 avec un budget de 88,5 millions de dollars. "Nous estimons que 1,1 milliard de dollars supplémentaires sont nécessaires pour atteindre le quart de l'objectif de couverture initiale de cette refonte, et qu'elle ne sera dans ces conditions pas réalisée avant 2020".

2011-2013 «Louvois», le logiciel fou, a été abandonné - Le logiciel Louvois a empêché le versement de la solde de dizaine de milliers de militaires durant deux ans, avant d'être abandonné. Coût : 460M€

Un bug informatique fait 9 morts et 14 blessés (octobre 2007, armée sud africaine) : un canon anti aérien Oerlikon, quatre cracheurs de balles de 35 millimètres, s'est retourné, tout en tirant, au hasard. Un bug informatique serait responsable.

12/10/2006 La "mauvaise utilisation" d'un logiciel à l'origine d'accidents de radiothérapie à Epinal - Entre mai 2004 et août 2005, des patients traités aux rayons pour des cancers de la prostate ont subi des surdosages dus à des erreurs de paramétrage d'un logiciel. Conséquences actuelles : 5 décès et des complications chez 721 patients... Cause : "erreur humaine". Cause réelle : "mauvaise ergonomie d'un logiciel obsolète".

29/12/2005 Cotisation retraite - Quelque 113 personnes ont eu la désagréable surprise de recevoir pour Noël un avis d'échéance de leurs cotisations retraite pour l'année 2006 de... deux milliards d'euros, un montant erroné dû à une erreur informatique, a-t-on appris mercredi de sources concordantes.

17/11/2005 Affaire du Rootkit Sony : sur-accident logiciel - Une infection nommée Backdoor.Win32.Breplibot.b tire parti du rootkit Sony DRM, système de protection contre les copies illicites Sony DRM, en fait un code empoisonnant le système d'exploitation des clients Sony dans le but innocent de prendre le contrôle des processus lancés. (Réseaux et Télécoms)

01/11/2005 Gros bug à la bourse de Tokyo, la plus importante d'asie, et ce sont toutes les cotations qui sont bloquées toute la journée.

29/09/2005 L'ensemble des dictionnaires Littré 2005 sont retirés des librairies aprés une coquille raciste dans ses colonnes : un "bug informatique" (un copier-coller mal maîtrisé) a conduit à la publication d'articles racistes tirés de l'édition de 1874 ! "Juif" était défini comme "Etre riche comme un juif, cherche à gagner de l'argent avec âpreté", nègre comme "La race des nègres".

Les pannes informatiques paraissent insupportables, les utilisateurs se sont habitués à une "informatique invisible" permanente dans un monde technologique que l'on ne peut plus débrancher.

Un bogue ou bug informatique est une anomalie dans un programme informatique l’empêchant de fonctionner correctement. Sa gravité peut aller de bénigne (défauts d’affichage mineurs) à majeure (explosion du vol 501 de la fusée Ariane 5). Ces erreurs involontaires de conception et de codage représentent un tiers du coût des sinistres informatiques ! La malveillance quant à elle cause 60% de ce coût.

Voici quelques bogues bien identifiées :


Voir d'autres conséquences de la non qualité.

 

On dit qu'il y a des bogues dans tous les logiciels, en petit nombre, et elles ne gênent généralement pas le fonctionnement du système et peuvent demeurer inconnues pendant une longue période. Par contre, certains logiciels sont dits bogués, ils contiennent beaucoup de bogues qui perturbent parfois gravement le fonctionnement du système.

De façon générale, les programmes des élèves (et des profs) ne marchent jamais du premier coup ! Pourtant ce sont des gens réputés intelligents ? Alors où est le problème ? Quelles sont les solutions ?

Un logiciel (Arrêté ministériel du 22 décembre 1981) est défini comme "un ensemble de programmes, de procédés, de règles, de documentation relatifs au fonctionnement d’un ensemble de traitement de l’information".

Etes-vous prêts à garantir la qualité des logiciels que vous écrivez ? Leur validite et leur fiabilité ? Pourriez-vous démontrer la qualité ?
Pourquoi hésitez-vous ?


" La programmation est aujourd'hui une course entre les
ingénieurs informaticiens qui essaient de construire des
programmes plus grands et mieux à l'épreuve des idiots,
et l'univers qui essaie de produire des idiots plus grands
et plus idiots. Jusqu'à présent, l'univers gagne."

Rich Cook

 

 

Les bogues surviennnent quand le logiciel ne correspond pas au besoin.

Un bogue est un non-respect de la spécification du système, c’est-à-dire de la définition de ses fonctionnalités, de ce que le système est censé faire. Un programme bogué est un programme dont la mise en œuvre ne vérifie pas la spécification.

 

Donc pour améliorer la qualité du logiciel, il y a des questions à se poser très en amont.

 

Portabilité

  • Utilisation d'un langage standardisé
  • Indépendance du matériel
  • Indépendance du système d'exploitatio
Utilité
  • Fiabilité
    • Précision
    • Intégrité
    • Tests réussis pour tous les cas
    • Uniformité de conduite
  • Efficacité
    • Economie de mémoire
    • Rapidité d'exécution
  • Aspect humain
    • Facilité d'utilisation
    • Accessibilité
    • Documentation pour l'utilisateur
Maintenabilité
  • Facilité de vérification
    • Autodocumentation
    • Vérifications formelles statiques possibles
    • Structuration
  • Clarté.
    • Structuration
    • Concision
    • Lisibilité
  • Facilité d'adaptation
    • Structuration
    • Facilité d'extension
    • Documentation technique


 

Le logiciel est la clé de différenciation des produits industriels.

Nous utilisons du logiciel tout le temps, de plus en plus volumineux :

O.S. Apple II (1977)

 

6 300 instructions

central téléphonique des années 80

 

1 M instructions

télescope Hubble

 

2 M instructions

drone

 

3,5 M instructions

noyau Linux
  3,7 M instructions
  système de combat du porte avions
Charles de Gaulle
  8 M instructions
portail Yahoo
  11 M instructions
Firefox
  10 M instructions
Android
  12 à 15 M instructions
WNT
  16,5 M instructions
W2K
  30 à 50 M instructions  
Microsoft Office
  45 M instructions
IDS (sous Reagan)
  50 M instructions
LHC du CNRSportail Yaho
  50 M instructions
Linux
  100 M instructions
automobile high tech (2013)
  100 M instructions
Direction générale de la comptabilité publique (Bercy)
  160 M instructions Cobol  
Catia
  200 M instructions ?

( voir une liste de tailles de logiciels
https://docs.google.com/spreadsheet/ccc?key=0Aqe2P9sYhZ2ndElxbjVTcnV2bHFOWmUwSkt2bjZLdVE&usp=drive_web#gid=5
et une infographie
http://www.informationisbeautiful.net/visualizations/million-lines-of-code/ )

90% des nouvelles fonctionnalités des automobiles sont apportées par l'électronique et l'informatique embarquées.
"Il y a plus d'informatique dans la Volvo S80 que dans le chasseur F15" déclarait en janvier 2000 le Président d'Audi.

Il y a, ou aura du logiciel partout : ampoules électriques, four à micro ondes, tissus des vêtements, stylos, livres, etc.

L'informatique sera omniprésente et invisible, dit-on. Ces déclarations doivent cependant être tempérées par les échecs courants de tout ce qui est futurologie :

"I think there is a world market for maybe five computers." [Thomas J. Watson Jr., PDG fondateur, IBM, 1943]
"There is no reason for any individual to have a computer in his home." [Ken Olson, PDG, Digital Equipment, 1977]
"Les ordinateurs du futur ne devraient pas peser plus de 1,5 tonnes." - Popular Mechanics, commentaires sur l'avancée des sciences, 1949

La voie de l'informatique "diffuse", "invisible", intégrée aux objets de la vie courante peut-elle concurrencer les ordinateurs personnels qui deviennent de plus en plus complexes ? L'exemple du couteau suisse est souvent employé pour parler du PC et de ses logiciels. Or dans une cuisine il est plus pratique d'employer plusieurs couteaux spécialisés... La connexion généralisée des objets sur internet ouvre de plus le champ de la communication entre ces objets intelligents (le réfrigérateur téléphone à l'épicier pour se réapprovisionner...).

IBM a annoncé en octobre 2001 travailler avec Citizen sur un prototype de montre sous Linux avec écran LCD, qui permettra de recevoir ses e-mails et de réserver ses billets de train, la WatchPad. http://www.vnunet.fr/svm/actu/article.htm?numero=8603

L'explosion du logiciel continue :

De 1965 à 1995, en 30 ans, le volume de chaque logiciel a été multiplié 100, alors que la productivité des développeurs n'augmentait que d'un facteur 3. C'est la crise du logiciel.

Si en 1977 le système d'exploitation de l'Apple II tenait en 6 300 lignes de code assembleur, développées en 7 semaines, 150 lignes/jour, en 1995, le développement de Microsoft Exchange Server a coûté 1 000 années x hommes pour 7 millions de lignes. La productivité a été de 30 lignes par homme par jour.
En 1999, le développement de Windows 2000 a ressemblé 5 000 ingénieurs pendant 3 ans pour réécrire 70% des 35 M ISL de NT. Productivité = 4,8 lignes par homme jour.
Cependant un bon hacker, motivé, seul, avec les bons outils, sans se préoccuper le cahier de scharges ou de relation client, peut écrire 3 000 lignes dans la même journée...

Et le progrès exponentiel de l'informatique parait devoir se poursuivre longtemps encore, poussé par le potentiel de puissance de chaque nouvelle génération de processeurs. En 1964, Gordon MOORE, le P.D.-G. fondateur de Intel, prédisait que le nombre de transistors dans les processeurs doublerait tous les 18 mois, augmentant leur puissance dans les mêmes proportions. Cette loi n'avait pas cessée d'être constamment vérifiée, mais depuis 1997 l'accélération dépasse nettement la prévision de Moore ! Moore est parti en retraite en 1998.

 

La loi de Moore ne doit pas etre confondue avec la loi de Murphy (http://www.multimania.com/courtois/murphy.htm), dite aussi loi de la tartine beurrée, ou loi de l'emmerdement maximum.

Dans un processus,
si à un moment donné plusieurs issues sont envisageables,
c'est vers l'issue la moins favorable que le processus s'orientera.

On maîtrise mal le développement des logiciels
"90% des projets informatiques sortent en retard" (Aberdeen)

Un nombre important de projets informatiques n'aboutissent pas aux logiciels répondant aux besoins des utilisateurs en respectant les contraintes de budget et de délai...


16 % des projets informatiques aboutissent (The Standish Group International (2002))
Source http://www.01net.com/article/212560.html

...contrairement au génie civil (ponts, autoroutes, tunnels,... - en excluant le cas du tram de Nancy !)...


Viaduc de Millau, décembre 2004, livré à temps, 310 M€

...bien que tous les grands projets doivent avouer des fautes cachées de jeunesse.

Le zéro défaut n'existe pas en matière de logiciel.

Le National Institute of Standards and Technology (NIST) estime à 60 milliards de dollars par an les pertes enregistrées par l'industrie et le commerce américains à cause des bogues contenus dans les logiciels. (S&T Presse USA - numéro 324 - 3 septembre 2002)

Personne ne sait aujourd'hui créer de logiciel sans défaut ! La validation de Windows 2000 avait fait appel à 600 000 bêta testeurs, il restait pourtant au lancement de sa commercialisation 63 000 problèmes potentiels dans le code, dont 28 000 sont réels.
Un logiciel commercial type contient entre 20 et 30 bugs pour mille lignes !

Bill JOY, de Sun, a écrit à propos de W2K : "ce système a atteint un niveau de complexité au delà de toute raison, il est tout simplement impossible de le déboguer".

Pourtant, il est possible de s'approcher d'une bonne qualité de logiciel :
"Le code de MySQL est 6 fois supérieur à la moyenne - La qualité du code MySQL a été mesuré par Reasoning, une compagnie indépendante qui étudie le code source des logiciels pour définir un indice de qualité. Elle scrute chaque ligne de code pour identifier des fautes comme l'utilisation de variables non initialisées, ou le déréférencement de pointeurs. Reasoning a trouvé un niveau d'erreur de 0,09 par millier de ligne de code pour MySQL. La moyenne de l'industrie, mesurée sur plus de 200 projets audité, se situe a 0,57 erreurs." ( http://www.nexen.net/actualites/tutoriel/le_code_de_mysql_est_6_fois_superieur_a_la_moyenne.php )

Les moyens mis en oeuvre pour le développement d'un logiciel définissent son niveau de maturité :

Niveau de maturité

Moyens

Résidu après codage

Erreurs résiduelles

Part de marché

1 bogue par

10 MISL : Bogues dans la navette

Niveau 1 individuel,
sans process
   
65 % ?
1/2 ligne ?  

Niveau 2

professionnel

700 erreurs pour dix mille

200 erreurs pour cent mille

30 %

500 lignes

20 000

Niveau 3

CASE

500 erreurs pour dix mille

50 erreurs pour cent mille

5 % ?

2 000 lignes

5 000

Niveau 5

redondance

200 erreurs pour dix mille

3 erreurs pour cent mille

exceptionnel

33 000 lignes

300

"La programmation c'est très simple, mais on se trompe toujours."
Claude PAIR

Au niveau 1, le processus est empririque, artisanal. Les pratiques ne sont ni systématiques ni formalisées, les résultats dépendent essentiellement des acteurs, le processus est instable, les risques client sont forts, les résultats non maîtrisables par avance.

Au niveau 2, le processus est documenté, il est reproductible. Un système de mesures est défini, les risques client sont faibles, l'efficience est à améliorer.

Au niveau 3, le processus est bien défini. Il est réglé, appliqué de façon correcte, un système de gestion et de mesure est mis en oeuvre, une capitalisation est mise en place.

Au niveau 4, le processus est dirigé, des prises de mesures quantitatives sont intégrées, elles sont exploitées pour prévoir et améliorer les performances du processus.

Au niveau 5, le processus est optimisé, l'amélioration continue du processus est intégrée dans le fonctionnement quotidien du projet (pilotage, étalonnage, amélioration).

 

Le mouvement inéluctable vers l'offshore, lorsqu'il est conduit dans une logique gagnant-gagnant, permet à nos sociétés occidentales de garder la maîtrise des processus et des prestations à valeur ajoutées, tout ce qui touche au knowledge management.
En 2003, l'industrie indienne du logiciel connaît une croissance à deux chiffres, que n'expliquent pas uniquement les prix pratiqués. L'Inde compterait 46 sociétés officiellement évaluées au niveau 5 de la démarche CMM (Capability Maturity Model), alors qu'il n'y en a aucune en France à ce jour. L'Inde se place ainsi juste derrière les Etats-Unis au plan mondial. Le prix n'est donc plus le seul argument. Les prix pratiqués en Inde ont pendant longtemps été très bas, le rapport était de 1 à 10. Actuellement ils sont sont de 30 à 40% moins chers qu'en France. Mais si vous ajoutez le coût des intermédiaires, des traductions, etc... le prix n'est plus l'argument essentiel, mais bien la qualité ! Il existe par ailleurs un risque social fort...
C'est l'occasion pour nos entreprises de se mettre à la hauteur des entreprises indiennes, en termes notamment de processus qualité ! Un peu comme dans les années 1980, dans l'automobile, où les Japonais nous dépassaient en termes de qualité totale. Nous avons réussi à refaire notre retard. En adoptant la démarche CMM, les entreprises du logiciel pourront reprendre la main.
Par JDNet Solutions (Benchmark Group) Mercredi 23 juillet 2003 http://solutions.journaldunet.com/0307/030723_inde.shtml

L'industrie du logiciel peut être comparée à une fabrication d'automobiles où le volant serait en option, les sièges remplacés par des tabourets non fixés au sol ; le levier de changement de vitesses serait dans le coffre (il suffit de s'arrêter, de descendre de voiture, de changer de vitesse, et de repartir, dirait le constructeur) et où la voiture serait généralement livrée sans portes ni pare brise sans que ces défauts puissent être pris en charge par la garantie.
La correction d'un défaut de conception ne serait pas le rappel des véhicules, mais la mise en vente d'un nouveau modèle.
De toutes façons à une panne d'essence le garagiste répondrait : il faut changer la carte mère le moteur.
(Voir le document Bill Gates et General Motors)

Les coûts du logiciel sont très élevés.

Windows 95 comportait 10 millions de lignes de code. Le coût du développement a atteint 2, 5 GF.
Cependant les 100 millions d'exemplaires vendus en 1996 ont rapporté 25 GF. Le bilan sur 1 an est donc de 10 fois la mise. Une telle rentabilité est une exception...

UPS, a investi 100 millions de dollars en 2000-2001 pour améliorer son système informatique, système nerveux de la gestion des livraisons. Le nouveau système d'information, DIAD III, transmet instantanément lesinformations au central lorsqu'un courrier est enregistré ou livré. Plus de 800 000 clients consultent chaque jour le site Internet d'UPS pour connaître l'état de la livraison et ils pourront maintenant consulter des informations quelques secondes après que celles-ci sont arrivées à l'entreprise postale. (S&T Presse, 16 juin 1999)

Le coût de développement d'un logiciel peut être estimé, très globalement, à 100 € par instruction.

A ce coût, il faut ajouter pour chaque instruction 2 000 € de maintenance !


Les coûts cachés sont des écueils invisibles et destructeurs

Pourquoi ?

La productivité obéit à une loi empirique, la loi des rendements décroissants, reliant MH, le coût en mois x hommes, et KISL, le nombre de milliers d'instructions sources livrées :

MH = 3,5 KISL ^1,2

Ainsi en une journée un programme de 20 à 25 lignes peut être développé, de A à Z.

Taille du logiciel

Coût ,en durée x hommes

21 lignes

1 JH

360 lignes

1 MH

1 000 lignes

3,5 MH

3 000 lignes

1 AH

5 000 lignes

2 AH

20 000 lignes

10 AH

100 000 lignes

70 AH

1 000 000 lignes

1 000 AH

10 000 000 lignes

20 000 AH

Le développement des 30 millions de lignes de code de W2K a mobilisé 5 000 ingénieurs, pour un coût de un milliard de dollars.
Mais attention, pour augmenter d'autant la productivité il se suffit pas d'augmenter la durée (René Trégouet : Concevoir un projet sur 1000 ans http://www.rtflash.fr/concevoir-projet-developper-sur-1000-ans-est-ce-aventure-hors-portee-pour-l-homme/article), ou d'augmenter l'investissement en hommes:


(Courbe de Raleigh)

Et d'autre part le coût effectif du développement subit de nombreuses corrections à effets multiplicatifs qui se cumulent:

Donc,

  1. il faut se doter d'une méthode de développement, phasée, et la respecter,

  2. la fin de chaque phase doit être actée et évaluée, il doit rester des documents.


Sachant qu'un programmeur écrit environ le même nombre de ligne de code par an,
indépendement du langage utilisé, la relation entre productivité et niveau d'abstraction
du langage est ainsi mise en évidence.

Les moyens de sortir de cette crise du logiciel sont connus, au moins en partie.

La rigueur vient toujours à bout de l'obstacle.
(Léonard de Vinci)

Une analyse fine du code de Linux a permis de détecter 985 bugs, sur 5,7 millions de lignes. Un logiciel commercial type en aurait contenu entre 114 000 et 171 000 bugs. Il est donc possible du code de qualité, mais pas totalement exempt de bugs...
Sur les 985 bugs identifiés (par des chercheurs de Stanfor dans Linux, 627 étaient inclus dans des parties critiques du programme. 569 pourraient déclencher un crash du système, 100 étaient des trous de sécurité (qui peuvent occasionner des fonctionnements anormaux d'une application) et 33 peuvent légèrement altérer la performance générale du système.

La cause principale de bogues semble bien être l'insuffisance des tests. Des tests bien conduits permettraient de réduire considérablement la facture. Il existe des procédures de tests dans les entreprises, mais les tests ne sont pas assez exhaustifs et les outils demeurent plutôt primitifs. "Des outils de tests standardisés, des scripts, des données de référence, des évaluations associés à un processus de certification rigoureux aurait un beaucoup plus large impact sur les insuffisances constatées actuellement". (National Institute of Standards & Technoogy (NIST), juin 2002)

Il faut s'imposer des processus formels de développement

Une spécification peut être en langue naturelle, informelle (comme « le logiciel convertit les euros en dollars et réciproquement »), ou formelle et précise, proche du langage mathématique (comme « tri(t) est une permutation de t telle que tri(t) est ordonnée pour la relation < »). Les bogues étant des défauts de réalisation des spécifications, bien spécifier avec précision est une nécessité !

Tester, tester, tester

Devant l'impossibilté de réaliser des tests exhaustifs d'un logiciel, les tests vonst surtout se porter sur les interfaces : interaction entre les différents modules, entre les différentes fonctionnalités, interactions entre le logiciel et le système d'exploitation, etc. Chaque test traite d'un élément précis de la conception ou de l'utilisation. Le but d'un test est de découvrir un défaut, mais si une batterie de tests ne montre pas de défaut cela n'implique pas que le logiciel est quand même exempt de défaut...

L'importance des tests peut conduire à les mettre en avant. Dans la méthode TDD (Test-Driven Development, développement guidé par le test), le principe rst d'écrire les tests avant le code, à l'inverse du cycle habituel programmer-tester-déboguer-retester-redeboguer-reretester... Le but est d'écrire le code le plus simple possible capable de franchir le test, le code -un objet- comportant alors strictement les fonctionnalités absolument nécessaires.

 

Pour maîtriser les coûts et la qualité

Cycle de vie d'un logiciel

Le concepteur de logiciels doit d’abord étudier les besoins de clients afin de voir ce qu’il peut apporter en matière d’adaptation informatique. Ensuite, il réalise un logiciel qui va combler les manques qui ont été repérés.

le modèle de la cascade : démarche linéaire

Phases Démarche
1

FAISABILITE

Apprécier l'opportunité de lancer un projet informatique. Choisir parmi les différentes possibilités.
2

ETUDE PREALABLE

Construire le Cahier des Charges : objectifs du futur système, comportement du système, donner à l'utilisateur final une représentation complète de ce qu'il aura comme système informatique.
3

SPÉCIFICATIONS     D'ENSEMBLE

Réécrire le CDC en terme de fonctionnalités,
spécifier : formalisation des fonctionnalités, au niveau global.
4

SPÉCIFICATIONS       DÉTAILLÉES

Raffiner les specs :
formalisation de chacune des fonctionnalités retenues.
5

CONCEPTION D'ENSEMBLE

Réécrire les specs d'ensemble en termes organiques :
identification globale de la structure du système, en terme de composants.
6

CONCEPTION DETAILLEE

Raffiner la conception :
identification de la structure de chaque composant.
7

CODAGE

Coder en L3G ou L4G chaque composant organique.
8

TESTS UNITAIRES

Tester la conformité du codage par rapport à la conception détaillée.
9

INTEGRATION

Tester l'assemblage des composants codés par rapport à la conception d'ensemble.
10

TESTS ALPHA

Tester l'existence de chacune des fonctionnalités par rapport aux specs détaillées.
11

TESTS BETA

Tester le comportement des fonctionnalités par rapport aux specs d'ensemble.
12

RECETTE

Tester le système par rapport au CDC.
13

MAINTENANCE

Corriger le système en fonction des rapports d'anomalie.
Faire évoluer le système en fonction de l'évolution de specs.
14

MIGRATION

Faire migrer les données du système vers un nouveau système.

Dans les documents de spécification, on mettra
- une description de l'environnement logiciel ;
- la définition de chaque fonction que doit offrir le logiciel, ce sont les specs fonctionnelles ; les tests de conformité se rapportent à ces définitions ;
- les comportement à adopter en cas d'erreur ; la robustesse du logiciel dépend de ces spécifications ;
- les contraintes que doit respecter le logiciel en termes de temps, espace, sécurité,... ; c'est une modélisation de l'efficacité du logiciel ;
- la définition des interfaces homme - machine ; la facilité d'utilisation est ainsi décrite dans ce document ;
- la définition des interfaces avec le matériel et les logiciels ; le degré de portabilité et d'interopérabilité en dépend.

Le cahier des charges décrira ce qu'attend le client, les contraintes de réalisation, choix de langages, de matériels, de normes d'interfaçage, de normes d'ergonomie. Le CDC ne doit contenir que des éléments mesurables : que vaudrait un contrat rédigé en termes subjectifs ?

 

le modèle de la cascade : à chaque phase correspond sa validation

  Phases Validation de fin de phase
1

FAISABILITE

validation de l'architecture, des concepts, du cycle de vie

2

ETUDE PREALABLE

validation de la planification, du budget, des délai, approbation du CDC en tant que contrat de réalisation

3

SPÉCIFICATIONS D'ENSEMBLE

validation de la spécification, production du manuel d'utilisation

4

SPÉCIFICATIONS DÉTAILLÉES

validation des spécification internes de chaque composant

5

CONCEPTION D'ENSEMBLE

validation, production du plan de tests d'intégration, création de la documentation technique

6

CONCEPTION DETAILLEE

validation, production du plan de tests unitaires

7

CODAGE

validation : inspection du code par une deuxième équipe

8

TESTS UNITAIRES

tests de chaque module : test de chaque instruction, chaque branchement

9

INTEGRATION

tests d'intégration des modules

10

TESTS ALPHA

tests des fonctionnalités

11

TESTS BETA

tests en vraie grandeur

12

RECETTE

tests de recette

13

MAINTENANCE

modifications, améliorations, correction d'erreurs

14

MIGRATION

 

Le coût des erreurs

Il faut utiliser une méthode de gestion de projet, avons-nous dit, donc phasée, mais...

Le coût de correction d'une erreur est à chaque phase multiplié par 10,
il faut donc détecter les erreurs au plus tôt.

 

L'informatique a créée beaucoup de"lois" pour décrire le décalage entre la théorie et la réalité :
Loi de Brooker : dix grammes d'abstraction valent des tonnes de bricolages.

Loi de Klipstein : les défauts n'apparaissent qu'après que le système ait passé (avec succès) la phase d'intégration.
Loi de Brook : doubler le nombre de programmeurs sur un projet en retard ne fait que doubler le retard.
Loi de Weinberg : si les architectes construisaient ds maisons comme les programmeurs écrivent les programmes, le premier picvert venu détruirait la civilisation.
Loi de Myers : on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement.

La gestion de projet informatique est décrite de façon très vraisemblable dans ce texte : La genèse. Au commencement était l'Appel d'Offres et l'Appel d'Offres était sans forme ni structure et l'obscurité s'étendait sur la face du Client, et la face du Client se détournait de la Compagnie... http://dchaffiol.free.fr/info/blagues/art_bg_specif_ter.htm

Cycle de vie d'un logiciel

Le modèle en V

- On produit des document de spécifications et de conception, qui sont validés par les parties en présence.
- Puis on réalise conformément aux cahiers de spécification et de conception, sans les remettre en cause.
- Ensuite on vérifie la conformité de la réalisation par rapport aux spécifications.

Il faudrait probablement mieux parler de cycle en M, la phase préalable de maturation du projet ainsi que la phase finale de déploiement et de maintenance étant aussi cruciales que les autres.

 

 

Les coûts de développement et de test

Une estimation grossière des coûts conduit à observer la répartition suivante :

Quant au coût de maintenance, on peut l'estimer à deux fois la somme des coûts conception + codage + test.

 

Le modèle conceptuel en cascade ou en V est efficace, il garantit généralement un logiciel de qualité, conforme au cahier des charges.
Mais il est lourd, de façon qui peut être excessive pour un petit projet, et ne convient pas lorsque l'expression des besoins ne peut être faite correctement.

Si les étapes du cycle de vie sont tout à logiques et utiles, en pratique l'analyse des besoins reste parfois incomplète car le client l'utilisateur final ne sait pas exprimer ses attentes, ou même ne les connait pas. Le produit livré a beau être conforme aux spécifications, le résultat ne correspond pas aux attentes réelles. De plus, il y a toujours une interprétation des documents qui induit un écart entre ce que l'utilisateur a imaginé et ce que l'intégrateur a compris, écart qui peut aller jusqu'à l'inutilité du produit. D'autres modèles du cycles de vie du logiciel peuvent tenter de pallier à ces difficultés.

 

Cycle de vie itératif, en spirale

Le cycle de vie itératif propose de répéter toutes les phases, tant que la validation n'est pas satisfaisante. Il s'agit en fait d'un cycle de vie en spirale. Ceci améliore la cohérence du projet et s'avère trés productif car le cycle itératif permet très tôt des retours sur :

Le cycle de vie itératif convient particulièrement bien à la conception objet, très modulaire et à base de réutilisation de composants logiciels. Il convient bien également au développement des grands sites web.

 

 

L'approche agile

méthode agile

Les méthodes agiles, comme Scrum, fonctionnent avec des « petits pas », qui font avancer progressivement, les « petits pas » étant menés en collaboration étroite entre les équipes de réalisation et le groupe de pilotage du projet. Il n'y a pas de grandes étapes, ni de longue phase d'étude, on prend les sujets qui se présentent les uns après les autres, au risque d'avoir à défaire ce qui avait été fait. Il n'y a pas de jalons, d'étapes de validation formelles, c'est le contact permanent des équipes qui garantit l'adéquation entre le résultat et les attentes. Ces méthodes peuvent mener à de très bons résultats. Cependant elles prennent plus de temps et d'énergie.

Dans le cas des méthodes agiles, la place des tests change :

tests méthodes agiles

(source)

En résumé, et sous forme de métaphore
(tiré d'une revue d'informatique des années 60) :

 

Nos études ont montré que la probabilité qu’un programme corrigé fonctionne comme avant la correction est seulement de cinquante pour cent.
Bev Littlewood & Lorenzo Strigini, Pour la Science (Janvier 1993)

En conclusion, on pourrait parfois croire que tout se passe comme si...

Références :

Rédiger un cahier des charges, fiche méthodologique http://www.awt.be/contenu/tel/ebu/ebu,fr,fic,070,000.pdf

Cahier des charges du site Web d'HEI http://www.barmarin.be/cours/webmaster/cahier-des-charges/CahierChargesWeb0.pdf

Les 10 pires bugs du monde http://www.wired.com/news/technology/bugs/0,2924,69355,00.html - Novembre 2005

 

Exercice

Ecole des Mines de Nancy

Document : http://tisserant.org/cours/qualite-logiciel/qualite_logiciel.html
Avril 1998 - Dernière mise à jour : octobre 2014

Remarques, suggestions, questions, ... : home