diff --git a/Cours7&8.md b/Cours7&8.md
new file mode 100644
index 0000000..2885067
--- /dev/null
+++ b/Cours7&8.md
@@ -0,0 +1,575 @@
+---
+title: "Génie logiciel, Séance 7 et 8"
+author: [SCHINDLER Hugo]
+date: \today
+titlepage: true
+...
+
+\newpage
+
+Objectifs et Moyens
+
+Qu'est ce qu'un bon logiciel ? Modularité, évolution, maintenance, ergonomique, compatibilité, efficacité, REPONSE AU BESOIN !
+
+# Qualité du logiciel
+
+**Fonctionnalité** : Répond aux besoins fonctionels avec exatitude (aptitude à la tâche, précision, sécurité)
+
+Exemple de la balance
+
+**Utilisabilité**
+
+- Facilité à prendre en main le logiciel : fonctionnalité de base : respect des habitudes du métier, ergonomie, contraste, performance (réactif : mettre un sablier)
+- Accompagner le changement (cession de formation, tuto video)
+- Facile à installer, utiliser et administrer. Pour les gros logiciels : plusieurs Usecase (machine à café : utilisation café et rechargement)
+
+**Fiabilité et robustesse**
+Fiabilté exprimé en nombre de neuf: disponible 99.9% indisponible 1.44 minute par jour. Plus on a de 9, plus on est robuste (on fait de la redondance : même logiciel sur 2 machines, 2 machines avec OS, logiciels différents (codé avec 2 teams différents) unplug à chaud. Plus c'est robuste, plus c'est cher. Interuption = perte de données d'argent. On cherche que le cout de robustesse soit égale à la perte due à la robustesse. Avantage de notre profil : pont de vue double. Détecter les problèmes, risques : difficile. On veut fonctionner en mode anormal : analyser, prévoir els erreurs, trouver où est l'erreur et rattrapper les bugs. Méchanisme exception Java.
+
+	 try{
+		entrer
+		sortie
+
+		} catch(IOException(Exception e){
+		  	code de tolérence : afficher un message d'erreur
+			Qu'est ce que je fais si l'excecution à planter
+		}
+
+**Efficacité** :
+
+- Temps de réponse (Exemple : logiceil de trading)
+- Consommation de ressources
+
+**Maintenance et évolutivité**
+
+- Correction de bugs
+- Facilité d'analyse et modification pour intégrer de nouveaux besoins
+- Non regression et facilité à être testé (en cas d'ajout d'une fonction, cela ne perturbe pas se qui est fait avant)
+
+**Portabilité**
+
+- Facile à installer
+- Facile à migrer
+- Extensibilité du nombre d'utilisateur
+
+**Objetctif du génie logiciel** : aboutir à une solution de qualité en respectant coût et délai.
+
+**Taux de succès des projets**
+
+- Succèes : Livrer en temps, cout ok : 25%
+- Imparfait : 1 seul des 2 critères : 50%
+- Echec : Projet dans le tiroir : 25%
+
+Dans le BTP, ce serait le bazar
+
+Les petis projets ont un meilleur taux de succès.
+
+**Origines de rsiques liées au développement de logiciel :**
+
+- incompréhension des besoins (logiciel unique, pas de référence commune comme en architecture)
+- instabilité des besoins (besoins qui évoluent)
+- Choix technologiques (developpement avec tel ou tel language, le language peut disparaitre à cause des architecture de technologies, support du créateur de language)
+- Mouvement du personnel (documentation difficile et longue, transmission oral souvent n binome maintenant. Difficile de récupérer les compétance. Bus number : nombre de personnes qui peuvent etre percutés par un bus sans que le projet se casse la gueule.
+- Pas de vecteur gravité (faire les choses dans le bon sens)
+
+**L'ecosystème du développement** facteur
+
+**Analyse de pestel:**
+
+- politique (logiciel libre)
+- economique (prix, formation logiciel)
+- sociaux (evolution de carière de votre équipe : en Europe la partie developpe n'est pas bien considérer. Aux US, ils sont très bien payés comme les bons commercials)
+- technologique (contrainte pour destop, tablette, smartphone, mais automatisation du code, veille technologique)
+- écologique (développement : code qui utilise le moins d'enregie : execution sur GPU ou CPU, organisation de l'équipe)
+- légaux (licence, CNIL (donnés personnelles))
+
+**Programme des cours CM8 à 11:**
+
+- qualité
+- métrqique
+- règles de bonne pratiques
+- tests
+- cycles et méthodes (concption, test, déployement)
+- patrons (solution classiques à problèmes classiques)
+- autres  outils suivant le temps restant
+- conclusion
+
+# Métrique
+
+On ne juge pas les développeur mais le logiciel pour savoir où l'améliorer
+
+## Metrique de code
+
+**NCSS** : **Non Commenting Source Statement** : 40..70/ méthode
+
+**CLOC** : **nombre de lignes de commentaires** : 10% ... 30%
+
+## Métrique Orientés objets
+
+**Profondeur de graphe d'héritage** : DIT : Profondeur 7 max hors bibliothèque
+
+**Coupling Between Objects** CBO : nombre de classes qu'une classe utilise (par trop spécifique, favorise modularité)
+
+**Weighted Methods per Class** (WMC) somme des métriques (complexité cyclomatique) pour toutes les méthodes
+
+## Mesure du logiciel
+
+**Points de Fonction** mesure de la richesse fonctionelle, taille du projet, en terme de fonctionnalités livrées à l'utilisateur
+
+**Complexité cyclomatique** nbArs-nbNoeuds+nbENtres+nbSorties : nombre minimum de chemin possible (faire le dessin)
+
+Exercice schéma 1
+
+Métrique : on doit l'interpréter, des codes peuvent l'examiner.
+
+puppycrawl.com/dtds/configuartion_1_3.dtd
+
+**Théorie de la complexité** Cf FISDA
+
+Il y a des logiciels pour faire les schémas (source monitor, testwell.fi, cmtjava, sonarqube (best), squale, klocwork)
+
+**Bonnes pratiques de développement**
+
+Toujours coder comme si celui qui maintient le code est un psycopathe qui sait où tu habites.
+
+## Conventions
+
+**Convention pour uniformiser le style du code :** facilite la relecture et maintenance par d'autres
+
+- Nommage et organisation des fichiers (build et srs)
+- Style d'indentation, taille des lignes
+- Nommage des méthodes, CONSTANTE, variables
+- Règles de commentaires et documentation, langue (anglais)
+- Règle de parenthèsage
+- Pas d'allocation dynamique si pas beaucoups de mémoire (code plus robuste)
+
+Périmètre de référenciels:
+
+- Code convention
+
+Enironment, projet :
+
+- .NET Coding techniques
+- Linux Kernel coding
+
+**Construction d'un référentiel:**
+
+- identifiant publique (article 2563)
+- public ciblé (architecte , développeur, testeur)
+- type de règle (norme>recommendation(entrose possible si justification)>bonne pratique)
+- regle courte mais multiple
+- contexte
+- controle de la règle (vérification manuelle, automatique)
+
+Vérification d'echantillons dans le code (nouveau developpeur, code critique, code pas bon précédement)
+
+
+# Test
+
+
+Test
+: exécution ou écvaluation d"='un système ou d'un composant ar des moyens automatiques ou manuels, pour vérifier qu'il répo,d à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus
+
+**Composant**
+
+- Données
+- Objet
+- Observation
+
+
+Enjeux des tests : s'assurer du niveau de qualité du produit livré. non-qualité = risque de bugs, panne et coûts directs et coûts caché. 30% budget =test, 80% pour NASA
+
+Un test= un investissement. Mais plus le bug est détecter tôt, moins il coûte cher.
+
+**Limites **
+
+- Pas de test exhaustif
+- Prouve la présence de bugs mais pas son abscence comme les aliens
+- Vu comme un poste de coût à réduire
+- Tests sautés pour livrer à temps
+- Testeur = fonction dénigré mais créatif et abstraction face au système
+
+**Catégories de test :**
+
+- A/ Proximité du code
+- B/ Granularité
+- C/ Qualité
+- D/ Dynamisme
+
+## Proximité du code
+
+A/ Test boîte magique
+
+**Test boîte noire :** point de vue de l'utilisateur. Est ce que ça marche ?
+
+**Test boîte blanche :** comment ça marche ? Données temporaires bien effacé, protocole sécurisé.
+
+**Test boîte grise :** Si on a pas accès à tout le code (appel de service extérieur), on les remplace par des bouchons pour tester.
+
+## B/ Granularité
+
+**test unitaire : **
+
+- Déclarationd d'une assertion
+
+- S'applique à une portion du code source
+
+- Vérifiable dès que le code est implémenté.
+
+**test d'assemblage**
+
+bon fonctionnement technique et fonctionnel de l'application à l'assemblage de ses différents composants
+
++Gros : **Recette**
+
+Test avec le client : 
+
+- Exhaustivité des éléments fournis 
+- Installation ok ?
+- Bon fonctionnement après installation
+- Cas d'erreur technique
+- Audit de code
+
+**Test en exploitation**
+
+- Vérification d'aptitude à la bonne exploitabilité
+- Test sur site pilote
+- Vérification de services réguliers
+
+**Test dans le cycle de vie**
+Cycle en V.
+On peut définir le test à chaque étape du cycle de vie.
+
+## C/ Critères de qualité
+
+**Assurance de qualité :**
+
+- Tests fonctionnels
+- Sécurité (tests hack classique)
+- Performance (temps de réponse pour 1 utilisateur, tests de charge(nombre d'utilisateur, de requêtes -> dimensionnement d'infrastructure) Ramasse miette qui se déclache avec le temps toute les 1 minutes
+- Non régression
+- Utilisabilité / ergonomie
+- Qualimétrie
+
+## D/ Dynamisme
+
+**Test statique**
+
+Examens du code sans exécution : identifier les trus louches : variable jamais lue, écrite 2 fois d'affiler sans lecture intermédiaire, affectation non réalisé, code jamais atteint : Eclipse nous le dit
+
+**Test dynamique**
+
+Pas possible de tester avec tout
+
+Comment concevoir les tests
+- test fonctionnels : trouve trou
+- test structurels : trouve erreur de programmation
+
+### Test fonctionnels
+
+**Test par partition d'équivalence** :
+: Hyp : ca fonctionnne avec un élément de la plage, alors ça fonctionne avec tous.
+
+**Test aux limites**
+: On test aussi les limites. Permet de détecter les boucles mal réglé sur les tableaux, vérifie les > et $\geq$
+
+**Test par table de décision**
+: Recherche de trou dans les décisions
+
+**Test par paires**
+: Si grands nombre de test à faire, on test que les paires au lieu de faire tout les cas.
+
+### Tests structurels :
+
+**Couverture des branches**
+: On choisit nos tests pour passer par tout les chemins.
+
+**Couverture des blocs**
+: Ne repésente pas le même travail si boucles dans le schéma.
+
+**Test aléatoire**
+: Un test complémenatire : détecte les erreurs de spécification. L'automatisation de la vérification de la sortie n'est pas facile.
+
+## Utilisation du test
+
+**Plannifier les tests : **
+
+- Stratégie (selon les spécifications, riques ou estimation des erreurs)
+- Tests (fonctionnel, sécurité)
+- parraléliser en attendant pas le code final : utilisation de bouchons
+- Priorite (plus critique, risque)
+- A quel moment ? big-bang
+
+descripton dans les standarts
+
+**Automatiser les test**
+
+- Framework génèrent des tests
+- Framework pour tester aspects (code, GUI, ...)
+
+**JUnit**
+- Environnement de tests unitaire en java
+- Definition des valeurs d'entrée
+- Exécution automatique
+
+On exprime le pourcentage de code testé au lieu du nombre de tests réalisés.
+
+Graphisme et audio difficles à tester automatique
+
+**Test par mutation**
+ : On modifie une ligne, le programme de test doit tuer tout les mutants.
+
+**Preuve formels**
+: démonstration mathématique (boucle infini, nombre de passage de boucles)
+
+Codage en B (ligne de métro météore)
+
+# Les cycles et méthodes de développement
+
+**Cycle en cascade**
+: années 70 : analyse, conception, implémentation, test, maintenance
+
+Inconvéniant :  effet tunnel : on ne sait pas si on satisfait les besoins du client.
+
+**Cycle en V**
+: Schéma 2, effet tunnel aussi
+
+**Cycle itératif ou incrémental** 
+: 1ere conception brute 
+
+**Inrémental **
+: on fait des morceaux complets
+
+**Itératif**
+: on fait des escisses.
+
+**Unified Process**
+
+- itératif et incrémental
+- piloté par cas d'utilisation, modélisation visuelle
+- architecture à base de composant (language objet)
+
+
+Manifeste agile : méthodes agiles : 4 principes : cf diapo
+
+Exemple de méthodes agiles :
+
+* Srum mêlée quotidienne
+* XP : eXtreme Programming : parie stratégique développées en binome rotatifs.
+* lean : ex : kanban (limiter les stocks, on écrit que le nécessaire)
+* Autres : ASD (Adaptative Developpement), crystal Clear, DSDM (Dynamic Systems Development Method)...
+
+Meilleur succès avec agile (moins de fail), mais projets waterfall sont moins propices à l'abandon. C'est peut etre une bonne chose.
+
+## Méthode d'estimation de coût du logiciel
+
+**Lois de parjkinson**
+: le projet se dilate sur le temps disponible
+
+**Loi du marché**
+: Combinen de temps je dois dire pour remporter le larché
+
+**Méthode analogique**
+: basé sur l'expérience des anciens projets
+
+**Méthode analytique**
+: somme de points coûts
+
+**Intégration continue**
+: basé sur une usine de développement logiciel. cf diapo
+
+# Patrons de conception (design pattern)
+
+Exemple : patron adaptateur
+
+Code pour adaptateur :
+
+     Cercle c=new Cercle(10, 2, 2);
+     CercleAdapt ca= new CercleAdapt(c);
+     lesMotifs.add(ca);
+     
+     ca.calculPerimetre();
+
+cf Schéma 3
+
+**Anatomie d'un patron**
+
+- Nom
+- But
+- Motivation: utilisation d'une classe sans renomer classe de base
+- Participant : target, adapter, adaptee, client
+- Structure avec UML
+- Exemple d'implémentation
+- Cas d'utilisation réel dans 3 situations réels
+- Problèmes connus
+- Conséquences (la classe de base peut moins facilement évoluer. 
+- Relation avec d'autres patrons
+
+Catégories :
+- Patrons de création
+- Patrons structuraux
+- Patrons comportementaux
+
+hillside.net/patterns solutions qui existent déjà
+
+## Singleton
+
+**Singleton**
+: Crer 1 seule instance d'une classe
+
+Code de class singleton :
+
+     public class Truc{
+     	    int machin;
+	    PRIVATE static Truc instanceUnique 
+     	    PRIVATE Truc(int m){
+	    	    this.machin=m;
+     	    }
+	    public static Truc getTruc(int m){
+	    	   if (instanceUnique==null){
+	   	       instranceUnique=new Truc(m);
+	    	   }
+	    	   return instanceUnique;
+	    }
+     }
+
+Attention en monothread uniquement ! 
+
+Code client :
+
+     Truc t = new Truc();
+
+Code autre :
+
+     class Machin{
+     	   int a
+     	   public STATIC int double(){
+	       	   return 2*a;
+     	   }
+     	   public int triple(){
+     	   	  return 3*a;
+    	    }
+     }
+
+
+c'etait un patron de création
+
+On doit connaitre le patron observer, singleton et Adapter
+
+Attente active : mettre des notifications à la place
+
+Interbloquage : sémaphore : programme risque de se bloquer
+
+Bad code smell : indice d'un problème.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+