Initial commit.

.gitignore

+.DS_Store
+cours_qualite_logicielle.pdf

Makefile

+pdf: cours_qualite_logicielle.md
+	marp -o cours_qualite_logicielle.pdf --allow-local-files cours_qualite_logicielle.md

cours_qualite_logicielle.md

+---
+marp: true
+theme: gaia
+_class: lead
+paginate: true
+backgroundColor: #fff
+backgroundImage: url('https://marp.app/assets/hero-background.svg')
+---
+
+![bg left:40% 80%](https://iut-charlemagne.univ-lorraine.fr/wp-content/uploads/2018/08/logo-orange-et-rouge.png)
+
+# **Qualité de Développement**
+
+### Des outils pour améliorer la qualité des logiciels
+
+**Laurent Pierron**
+Laurent.Pierron@inria.fr
+
+BUT Informatique S4 Groupe B
+Janvier-Février 2023
+
+---
+
+# TP 1 : Sphère
+
+Prise en main des outils et du processus de qualité de développement pour Java avec Maven :
+https://gitlab.univ-lorraine.fr/pierron9/sphere
+
+```bash
+git clone https://gitlab.univ-lorraine.fr/pierron9/sphere
+cd sphere
+git branch pierron9
+git switch pierron9
+mvn verify -q
+code . # Your favorite IDE
+```
+
+---
+
+# Un développement de qualité ?
+
+Dépend du point de vue :
+-   Ordonnateur 
+-   Concepteur 
+-   Développeur
+-   Vendeur
+-   Acheteur
+-   DSI / Exploitation
+-   Utilisateur
+
+---
+
+# Un développement de qualité ?
+
+Des caractéristiques :
+* **Capacité fonctionnelle** : Le logiciel répond-il aux besoins de ses utilisateurs ?
+* **Fiabilité** : Le logiciel est-il en mesure d’assurer un niveau de qualité de service suffisant pour satisfaire les besoins opérationnels de ses utilisateurs ?
+* **Facilité d'utilisation** : Le logiciel peut-il être utilisé à moindre effort ?
+
+---
+
+# Un développement de qualité ?
+
+Des caractéristiques :
+* **Maintenabilité** : Est-il facile d’adapter le logiciel à de nouveaux besoins ou à de nouvelles
+contraintes ?
+* **Rendement / Scalabilité** : Les ressources matérielles nécessaires à l’exécution du logiciel sont-elles en rapport avec sa rentabilité ?
+* **Portabilité** : Le logiciel peut-il être transféré facilement d’une plate-forme ou d’un environnement à un autre ?
+* **Exploitabilité** : Le logiciel est-il facile à installer, à mettre à jour, à diagnostiquer et à superviser ?
+
+---
+
+# Fiabilité
+
+Fiabilité : le coût visible de la non-qualité
+
+Des problèmes :
+* 2009 : erreur d'arrondi assurance vieillesse => 2,5 milliards d'euros
+* 1996 unités différentes => sonde Mars Climate Orbiter s'ecrase
+* 1996 : changement codes d'erreurs sur ATM de First National Bank => 750 milliards dollars
+
+---
+
+
+# Fiabilité
+
+Fiabilité : le coût visible de la non-qualité
+
+Des solutions :
+* Assurance Vieillesse : tests unitaires
+* Sonde : tests d'intégration
+* ATM : test de non-régression
+
+Problème de coût des tests, calculer le ROI
+
+Eviter la sur-qualité
+
+---
+
+# Maintenabilité
+
+Tolérance au changement : le coût caché de la non-qualité
+
+**Maintenance corrective** : correction de défaut, refonte d'algorithme, retour à un état antérieur
+
+**Maintenance évolutive** : ajout d'une fonctionnalité, adaptation aux nouvelels exigences, adapation nouvelle législation
+
+=> Nombre de lignes produites après 1ere mise en service < nombre de lignes des versions successives
+
+---
+
+# Améliorer la tolérance aux changements
+
+Solutions :
+
+* les tests et leur automatisation
+* la conception
+* la lisibilité du code source
+* le développement *Agile**
+
+![bg top:60% 90%](images/sonar_quality.webp)
+
+---
+
+# Les Tests
+
+Plusieurs types :
+
+* Fonctionnels
+* Unitaires
+* Intégration
+* Charge
+* Non régression
+
+---
+
+![bg left:30% 90%](images/BDD_TDD.webp)
+
+# Tests Fonctionnels
+
+Test, comme un utilisateur, le comportement du logiciel demandé par l'*Ordonnateur*.
+Décrits dans le cahier des charges.
+Idéalement écrits avant le code : méthode *BDD* (Behavior Driven Development)
+
+Usages annexes : documents de recette, documentation utilisateur
+
+Des outils suivant le type d'application finale : scripts (CLI), Sélenium (Web)
+
+---
+
+![bg left:30% 90%](images/BDD_TDD.webp)
+
+# Tests Unitaires
+
+Test chaque fonction séparément. Le résultat doit correspondre aux spécifications données lors de la conception.
+Idéalement écrits avant le code : methode *TDD* (Test Driven Development)
+
+Usages annexes : documentation codeur/mainteneur, non-régression
+
+Des outils suivant le langage de programmation : JUnit, PHPUnit, etc.
+
+---
+
+# Tests d'Intégration
+
+Tests complets de tous les modules ensemble dans un environnement identique à la production.
+Notion de serveur de *qualification*.
+
+Pas d'outils spécifiques.
+
+---
+
+# Tests de Charge
+
+![bg left:40% 80%](images/monitoring-dashboard.webp)
+
+Tests permettant de s'assurer que l'application fonctionnera correctement quand la taille des données et/ou le nombre d'utilisateurs augmente.
+
+Des outils : JMeter, HammerDB, JMH, gProfiler, BlackFire.io, etc.
+
+---
+
+# Tests de Non-Régression
+
+60 à 80% du code produit lors de maintenance évolutive ou corrective
+
+Assurer que le programme fonctionne toujours correctement
+
+1 **BUG** => 1 **TEST** : tout bug doit faire l'objet d'un test automatique pour le mettre en évidence
+
+---
+
+# Couverture des tests
+
+*Que valent mes tests, quantitativement et qualitativement ?*
+
+*Quelle est leur couverture technique et fonctionnelle ?*
+
+Technique : à faire automatiquement lors des tests, couvrir le maximum de lignes de code :
+- compéter les tests
+- supprimer le code inutile
+
+Fonctionnel : à l'usage, peut nécessiter des testeurs professionnels en plus d'automates
+
+---
+
+# Tests : Efficacité
+
+Trouver des bogues au plus tôt
+
+*Un test fait pour trouver des bogues a une valeur*
+
+*Un test fait pour réussir/passer n'a pas de valeur*
+
+Un test doit d'abord échouer.
+Plus les détections de bogues sont faites tôt moins le coût de détection est élevé.
+
+---
+
+# Tests : Automatisation
+
+Pourquoi automatiser :
+- valider rapidement des modifications
+- détecter au plus tôt des anomalies
+
+Investissement obligatoire en mode *Agile*
+
+----
+
+# Tests : Amélioration continue
+
+**Zéro défaut n'existe pas !**
+
+En cours de production des anomalies apparaissent, questionnement :
+- Spécifications erronées, incomplètes
+- Couverture des tests trop faible
+- Code trop complexe
+- Paramétrage incomplet
+
+Créer des tests mettant en évidence le problème. Corriger et améliorer le logiciel.
+
+---
+
+# Tests : Coût réel
+
+Tests ont un coût mais garantissent : conformité, fiabilité et qualité
+
+Voir les tests comme une assurance
+
+En conclusion : **tester au plus tôt**, **tout au long** du développement, **automatiser** le plus possible les tests.
+
+---
+
+# TP 2 : Calculator
+
+Un TP plus conséquent avec du *refactoring* de code :
+
+https://gitlab.univ-lorraine.fr/pierron9/calculator
+
+```bash
+git clone https://gitlab.univ-lorraine.fr/pierron9/calculator
+cd calculator
+git branch pierron9
+git switch pierron9
+mvn verify -q
+code . # Your favorite IDE
+```
+
+---
\ No newline at end of file