Téléverser un nouveau fichier
This commit is contained in:
hschindler
parent
17c351edd2
commit
e51ba786a1
1 changed files with 575 additions and 0 deletions
575
Cours7&8.md
Normal file
575
Cours7&8.md
Normal file
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in a new issue