94 lines
4.5 KiB
Plaintext
94 lines
4.5 KiB
Plaintext
|
Autres outils de sureté d'un programme
|
||
|
|
--------------------------------------
|
||
|
|
|
||
|
|
La preuve de programme
|
||
|
|
~~~~~~~~~~~~~~~~~~~~~~
|
||
|
|
|
||
|
|
Le niveau maximum de sûreté d'exécution d'un programme est la preuve. Qu'est-ce que la preuve
|
||
|
|
formelle d'un programme ? Selon la définition de Wikipédia, ce sont "des techniques permettant de
|
||
|
|
raisonner rigoureusement, à l'aide de logique mathématique, sur des programmes informatiques ou
|
||
|
|
du matériel électroniques, afin de démontrer leur validité par rapport à une certaine
|
||
|
|
spécification." Bref c'est un raisonnement logique sur un programmme qui permet d'être sûr que le
|
||
|
|
programme est valide et ne va pas planter.
|
||
|
|
|
||
|
|
La preuve de programme est très peu utilisée dans l'industrie, car très coûteuse et très
|
||
|
|
difficile à mettre en place. Elle quand même utilisée, mais dans des secteurs où le risque doit
|
||
|
|
absolument être évacué et où il n'y a aucun droit à l'erreur. Par exemple, le secteur médical
|
||
|
|
(informatique en bloc opératoire), militaire (peu d'informations nous parviennent dans ce
|
||
|
|
domaine), l'aviation civile (le logiciel Astrée pour Airbus), la fusée Ariane (depuis le bug qui
|
||
|
|
avait fait crasher Ariane 5 ces questions sont prises très au sérieux), et le milieu bancaire
|
||
|
|
(surtout le domaine des décisions boursières : un programme chargé de lancer des décisions
|
||
|
|
d'achat ou de vente à la bourse qui comporte un bug peut en quelque centièmes de secondes faire
|
||
|
|
perdre des millions, voire des milliards d'euros à une banque. Le programme ne doit tout simplement pas
|
||
|
|
bugger).
|
||
|
|
|
||
|
|
Le model checking
|
||
|
|
~~~~~~~~~~~~~~~~~~
|
||
|
|
|
||
|
|
Le model checking, l'analyse statique et l'interprétation abstraite procèdent d'une méthodologie
|
||
|
|
moins lourde de validation des programmes. Ces méthodes analysent exhaustivement l'évolution du
|
||
|
|
système lors de ses exécutions possibles et permetent de dire si globalement, dans un contexte
|
||
|
|
donné, le programme va fonctionner correctement. Encore très lourdes, ces techniques ne sont
|
||
|
|
utilisées que dans un contexte industriel de haute sécurité.
|
||
|
|
|
||
|
|
Les tests d'acceptation
|
||
|
|
~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
|
|
||
|
|
Il y a plusieurs types de tests
|
||
|
|
|
||
|
|
- unitaires
|
||
|
|
- fonctionnels
|
||
|
|
- acceptation
|
||
|
|
|
||
|
|
Très utilisés dans l'industrie, les tests unitaires et fonctionnels ne testent que certaines
|
||
|
|
parties du programme et permettent de dire que le programme va marcher grosso-modo à peu près.
|
||
|
|
Beaucoup moins coûteux à installer, ce sont des éléments cléfs des méthodes agiles.
|
||
|
|
|
||
|
|
Les Outils de linting (validation)
|
||
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
|
|
||
|
|
- vérifications syntaxiques
|
||
|
|
- vérification sémantiques
|
||
|
|
- vérification sur les imports inutiles ou mal formés (imports croisés
|
||
|
|
|
||
|
|
Exemple en python : pylint
|
||
|
|
|
||
|
|
|
||
|
|
La dette technique
|
||
|
|
~~~~~~~~~~~~~~~~~~
|
||
|
|
|
||
|
|
Au bout d'un moment le code devient du code spaghetti et les techniques sont obsolètes.
|
||
|
|
Les tests permettent de solder la dette technique plus facilement.
|
||
|
|
|
||
|
|
**avoir le courage de payer une dette technique, et affronter une dette technique
|
||
|
|
sinon il peut y avoir un coût à payer qui sera pohibitoire.**
|
||
|
|
|
||
|
|
On solde la dette technique parce que à un moment ça va devenir beaucoup trop
|
||
|
|
cher à payer.
|
||
|
|
|
||
|
|
Les méthodologies agiles
|
||
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
|
|
||
|
|
La manière dont le code est produit importe énormément. Par exemple, une
|
||
|
|
méthodologie ou le **refactoring** (réécriture de code) est permis et même conseillé
|
||
|
|
a plus de chance de produire du code organisé.
|
||
|
|
|
||
|
|
Les méthodologies agiles produisent en général du code mieux organisé. Ce sont les
|
||
|
|
méthodes de travail les plus en vogue aujourd'hui, elles mettent l'accent sur :
|
||
|
|
|
||
|
|
- Du logiciel fonctionnel plutôt que de la documentation exhaustive
|
||
|
|
- La réponse au changement plutôt que le suivi d'un plan
|
||
|
|
- Le logiciel fonctionnel est la principale mesure d'avancement
|
||
|
|
- Une attention continue à l'excellence technique et à une bonne
|
||
|
|
conception améliore l'agilité
|
||
|
|
- La simplicité est essentielle (il est facile de faire, il est
|
||
|
|
difficile de faire simple)
|
||
|
|
|
||
|
|
Le principe de base de la méthodologie Scrum par exemple est de focaliser l'équipe de façon
|
||
|
|
itérative sur un ensemble de fonctionnalités à réaliser, dans des itérations de durée fixe de une
|
||
|
|
à quatre semaines, appelées **sprints**. Chaque sprint possède un but à atteindre, défini par le
|
||
|
|
responsable de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans ce
|
||
|
|
sprint. Un sprint aboutit toujours sur la livraison d'un produit partiel fonctionnel. Pendant ce
|
||
|
|
temps, le facilitateur a la charge de réduire au maximum les perturbations extérieures et de
|
||
|
|
résoudre les problèmes non techniques de l'équipe.
|