Licence Professionnelle Web et Applications Mobiles

Tianxiao.Liu@u-cergy.fr

Sommaire

Notions de base de l’agilité du projet

Méthode agile XP (Extreme programming)

Planification et releases

Pair-programming

Tests de projet

Intégration continue

Qualité de projet

Modèle Mc Call

Prototype (maquette)

Prototype

L’embryon du produit initial : "Je saurai ce que je veux quand je le verrai."

Viser à livrer rapidement une maquette de la solution à développer avec un minimum de fonctions viables

Clarifier les besoins afin d’y arriver à une meilleure définition des spécifications fonctionnelles et techniques

Eviter l’écart entre les besoins réels, ceux exprimés et ceux interprétés

3

Effet Tunnel : deux types

Effet tunnel Point de départ : connu Point d’arrivée : inconnu

Pour les clients Pendant très longtemps, pas de communication avec

les membres de l’équipe de projet Grand risque d’avoir un résultat non satisfaisant !

Pour les développeurs De grandes phases de refactoring du code

4

Rester dans le

tunnel noir

Développement itératif : principes

Découpler le projet en plusieurs étapes d’une durée courte Les itérations

Pour chaque itération, une version (release) intermédiaire est requise.

Intégration des fonctionnalités au fur et à mesure

Le système s’enrichit progressivement.

Niveau de satisfaction des clients

Niveau de qualité requis

5

Développement itératif : avantages

La communication est de meilleure qualité.

La visibilité est meilleure.

La qualité est évaluée en continu.

Les risques sont détectés très tôt.

L’équipe prend confiance.

Les coûts sont contrôlés.

6

Releases fréquentes et le plus tôt possible

Regrouper les fonctionnalités les plus importantesdans la première release

7

Mois 1 2 3 4 5 6 7

Release 1

Release 1Release 2

$$$$$

$$$ $$$ $$$

$$

$$$

Principes de pair-programming

On s’entraide pour la réussite.

Une approche très puissante : brain storming

Principes de base Deux rôle: « conducteur » et « observateur »

Conducteur : celui qui programme

Observateur, celui qui réfléchit

A quoi réfléchit-t-il l’observateur ? Quelles sont les prochaines étapes (tâches)

Le programme actuel est-il cohérent avec la conception globale du projet ?

8

Astuces pour pair-programming

Utilisez-le pour les programmes à maintenir. Ne pas imposer les binômes. Change de binôme pour « rafraîchir ». Environnement de travail efficace. Production collective du programme. Ne

pas critiquer. Changez de rôle fréquemment.

9

Tests de projet

Pourquoi a-t-on besoin de tester les systèmes informatiques ?

Le système est conçu et réalisé par les humains erreurs humaines !

Etudes des cas où il y a eu des problèmes de tests catastrophe !

10

Cas 1 : Sonde Mariner 1 – 1962

11

Une erreur de trait d'union désastreuse !

130 millions dollars perdus !

Cas 2 : Therac-25 - 1985

12

Erreur informatique : bug logiciel

5 morts !

Cas 3 : Ariane 5 Vol 501 - 1996

13

Explosion à cause d'un dépassement d'entier dans les registres mémoire

370 millions dollars perdus !

Coûts des bugs

14

0

100

200

300

400

500

600

700

800

900

1000

Implémentation Intégration Recette Utilisation

Coût bug

Définition du test

Le test est l'exécution ou l'évaluation d'un système ou d'un composant, par des moyens automatiques ou manuels, pour vérifier qu'il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus

Proverbe connu : Tester peut révéler la présence d'erreurs mais jamais leur absence.

15

Les notions de base

Objectif de test

comportement du système envisagé

Données de test

données en entrée au système de manière à déclencherl'objectif de test

Résultat de test

conséquence ou sortie de l'exécution du test

Case de test (test case)

Objectif + données + résultat de test

16

Test : méthodologies

Test boîte noire

Spécification (Cahier des charges) tester

Sans connaître l'implémentation technique

Test pouvant être prédéfini

Test boîte blanche

Tester en se basant sur le code source

Tester pour du code déjà écrit

17

Les types de tests

Test unitaire

Tester une unité de programme de façon isolée

Sans appel à d'autres fonctions

Test d'intégration

Tester le fonctionnement d'un ensemble de modules (via leur interface)

Test de système

D'un point de vue d'utilisateur

Conformité du produit fini

18

Intégration continue (CI)

TDD (Test Driven Development)

Réduire le risque d'intégration

Détecter les problèmes d'intégration le plus tôt possible

Le test immédiat des modifications

Avoir toujours une version stable et viable

19

Environnement de travail de CI

Un dépôt de source partagée

Logiciel de gestion de version : SVN, Git…

Tout le monde travaille sur la branche principale (trunk) –Intégration des modifications

Chaque développeur fait des commits régulièrement (au moins une fois par jour).

Des builds et des tests automatisés

Serveur de CI (ex. Hudson) : compilation et lancement des tests automatiques (à chaque commit)

20

Environnement de travail de CI

Logiciel de gestion des tâches

Une tâche = un cas (case)

Avant que la tâche soit finie, des tests automatisés correspondant sont déjà écrits par le Q.A.

Tâches finie par le développeur tests activés dans la test suite

Compétence du Q.A.

Prédéfinir les tests n'est pas toujours un travail facile : techniques de mock, complétude …

21

Pour faire un commit

Les conditions strictes Il faut que le code compile …

Il faut que tous les tests qui passaient avant passent encore maintenant

Commit pour une tâche

Lancer manuellement les tests correspondants

Qualité de code

○ Nettoyer les petits « bricolages »

○ Cohérence, convention de codage, design patterns…22

Pour faire un commit …

23

9H – 10H 10H – 11H30 11H30-12H

Test suite failed…12H-13h30 13H30-14H

Test suite failed…

BavardéPause café priseMangéFnac faitQuoi maintenant ?

Integration Test Suite

L'ensemble de tous les tests Une couverture entière

Des tests unitaires + des tests d'intégration entre les modules architecturaux

Des milliers de tests automatisés

Dont l'exécution nécessite des heures !

Bien que idéal, il est impossible de lancer cette test suite avant chaque commit…

24

Submit Test Suite

Un sous-ensemble de Integration Test Suite Le Q.A. choisit soigneusement des tests significatifs

et sensibles pour y mettre dans Submit Test Suite.

Normalement, ceci doit couvrir >95% des cas.

Son exécution doit être de quelques minutes

Il n'y aura plus bavard, pause café, fnac…

25

A l'entreprise : Jour J du projet

26

Qui a cassé la submit test suite ?!!

Vu le dashboard, c'est lui !

AH Ô… mais ça passait chez moi…

Q A

Build de la nuit et régression

Serveur CI Lancement de Integration Test Suite

Tests échoués (cas) régression Priorité N° 1

27

T'es sur quoi là ?

Ben, je suis sur la tâche X, comme prévu.

Pourquoi tu ne résous pas le cas de régression ?!

Ah, je n'ai pas vérifié mes emails…

Esprit de qualité de projet

Principe de base

On dit ce que l'on fait et on fait ce que l'on a dit.

Une tâche parfois difficile dans un projet

On est souvent réticent à la mise en place d'une politique de qualité

Contrôles parfois perçus comme une surveillance du travail des membres de l'équipe…

Solution envisagée

La qualité est bien l'affaire de tous et toute l'équipe doit être impliquée

28

Assurance de qualité : démarche

PLAN : écrivez ce que vous faites (définissez qui, quoi, où, quand, comment assurer la qualité)

DO : faites ce que vous avez écrit

CHECK : vérifiez ce que vous avez fait est conforme à ce que vous avez écrit

ACT : validez

29

Modèle Mc Call : Exploitation

Conformité par rapport aux besoins (l’application répond-elle aux besoins des utilisateurs ?)

Fiabilité (l’application fonctionne-t-elle correctement dans tous les cas ?)

Efficacité (utilisation minimum des ressources, c’est-à-dire temps, mémoire …)

Intégrité (l’application est-elle bien protégée, le niveau de sécurité est-il suffisant ?)

Facilité d’emploi (mise en œuvre, prise en main)

30

Modèle Mc Call : Evolution et Adaptabilité

Maintenabilité (est-il facile de localiser et de corriger les erreurs ?)

Souplesse (facilité de modification et d’évolution)

Testabilité (quels efforts à fournir pour tester le système ?)

Portabilité (le système est-il utilisable sur une autre machine ?)

Réutilisabilité (peut-on reprendre certaines parties du projet et les intégrer dans un autre logiciel ?)

Interopérabilité (peut-on interfacer l’application avec un autre système ?)

31