Qu'est ce qu'un logiciel de qualité

625 vues

Publié le

Quelques slides pour réfléchir sur la notion de qualité pour un logiciel et des méthodes pour la mesurer

Publié dans : Logiciels
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
625
Sur SlideShare
0
Issues des intégrations
0
Intégrations
8
Actions
Partages
0
Téléchargements
53
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Versionner la documentation
    Générer la documentation
    Collaborer pour améliorer la documentatio
  • http://www.bullseye.com/minimum.html

    https://en.wikipedia.org/wiki/Usability_testing

    https://en.wikipedia.org/wiki/System_testing

    https://en.wikipedia.org/wiki/Sanity_testing

    http://www.tutorialspoint.com/software_testing_dictionary/acceptance_testing.htm

    http://agiledata.org/essays/tdd.html

    http://fr.slideshare.net/edvorkin/unit-testing-with-spock-framework?next_slideshow=1

    http://www.bullseye.com/minimum.html
  • http://www.bullseye.com/minimum.html

    https://en.wikipedia.org/wiki/Usability_testing

    https://en.wikipedia.org/wiki/System_testing

    https://en.wikipedia.org/wiki/Sanity_testing

    http://www.tutorialspoint.com/software_testing_dictionary/acceptance_testing.htm

    http://agiledata.org/essays/tdd.html

    http://fr.slideshare.net/edvorkin/unit-testing-with-spock-framework?next_slideshow=1

    http://www.bullseye.com/minimum.html
  • http://www.bullseye.com/minimum.html

    https://en.wikipedia.org/wiki/Usability_testing

    https://en.wikipedia.org/wiki/System_testing

    https://en.wikipedia.org/wiki/Sanity_testing

    http://www.tutorialspoint.com/software_testing_dictionary/acceptance_testing.htm

    http://agiledata.org/essays/tdd.html

    http://fr.slideshare.net/edvorkin/unit-testing-with-spock-framework?next_slideshow=1

    http://www.bullseye.com/minimum.html
  • Versionner la documentation
    Générer la documentation
    Collaborer pour améliorer la documentatio
  • Versionner la documentation
    Générer la documentation
    Collaborer pour améliorer la documentatio
  • http://www.bullseye.com/minimum.html

    https://en.wikipedia.org/wiki/Usability_testing

    https://en.wikipedia.org/wiki/System_testing

    https://en.wikipedia.org/wiki/Sanity_testing

    http://www.tutorialspoint.com/software_testing_dictionary/acceptance_testing.htm

    http://agiledata.org/essays/tdd.html

    http://fr.slideshare.net/edvorkin/unit-testing-with-spock-framework?next_slideshow=1

    http://www.bullseye.com/minimum.html
  • http://www.bullseye.com/minimum.html

    https://en.wikipedia.org/wiki/Usability_testing

    https://en.wikipedia.org/wiki/System_testing

    https://en.wikipedia.org/wiki/Sanity_testing

    http://www.tutorialspoint.com/software_testing_dictionary/acceptance_testing.htm

    http://agiledata.org/essays/tdd.html

    http://fr.slideshare.net/edvorkin/unit-testing-with-spock-framework?next_slideshow=1

    http://www.bullseye.com/minimum.html
  • http://www.bullseye.com/minimum.html

    https://en.wikipedia.org/wiki/Usability_testing

    https://en.wikipedia.org/wiki/System_testing

    https://en.wikipedia.org/wiki/Sanity_testing

    http://www.tutorialspoint.com/software_testing_dictionary/acceptance_testing.htm

    http://agiledata.org/essays/tdd.html

    http://fr.slideshare.net/edvorkin/unit-testing-with-spock-framework?next_slideshow=1

    http://www.bullseye.com/minimum.html

    http://asq.org/learn-about-quality/cost-of-quality/overview/overview.html
    le coût de réécrire une partie (refactoring)
    le coût de retester une fonctionnalité
    le coût de refabrication, d’installation, mise à jour déploiement...

  • n = Number of resources required
    R = Rate (hourly average) of resource
    H = Hours required
    C = Costs associated with benefits, payroll, recruitment (usually ~40% of hourly rate)
    HC = Hardware Costs
    SL = Software Licenses
    MI = Migration and Implementation expenses (e.g. consulting engagements, training, etc)

  • ANomalie : Toute condition qui dévie des attentes basées sur les exigences de spécifications, documents de conception, documents utilisateurs, standards etc, ou des perceptions ou expériences de quelqu’un. Les anomalies peuvent être trouvées pendant, mais pas uniquement, les revues, tests, analyses, compilations ou utilisation des produits logiciels ou de la documentation applicable [IEEE 1044]. Voir aussi défauts, déviation, erreur, faute, défaillance, incident, problème.

    Incident : lié au tests
    Defauts :
    Anomalies :Ecart aux spec
    Defauts = Bug livrés


  • ANomalie : Toute condition qui dévie des attentes basées sur les exigences de spécifications, documents de conception, documents utilisateurs, standards etc, ou des perceptions ou expériences de quelqu’un. Les anomalies peuvent être trouvées pendant, mais pas uniquement, les revues, tests, analyses, compilations ou utilisation des produits logiciels ou de la documentation applicable [IEEE 1044]. Voir aussi défauts, déviation, erreur, faute, défaillance, incident, problème.
  • ANomalie : Toute condition qui dévie des attentes basées sur les exigences de spécifications, documents de conception, documents utilisateurs, standards etc, ou des perceptions ou expériences de quelqu’un. Les anomalies peuvent être trouvées pendant, mais pas uniquement, les revues, tests, analyses, compilations ou utilisation des produits logiciels ou de la documentation applicable [IEEE 1044]. Voir aussi défauts, déviation, erreur, faute, défaillance, incident, problème.
  • ANomalie : Toute condition qui dévie des attentes basées sur les exigences de spécifications, documents de conception, documents utilisateurs, standards etc, ou des perceptions ou expériences de quelqu’un. Les anomalies peuvent être trouvées pendant, mais pas uniquement, les revues, tests, analyses, compilations ou utilisation des produits logiciels ou de la documentation applicable [IEEE 1044]. Voir aussi défauts, déviation, erreur, faute, défaillance, incident, problème.
  • Qu'est ce qu'un logiciel de qualité

    1. 1. La qualité logicielle
    2. 2. Hello! Je suis Sylvain Leroy Vous pouvez me trouver sur : sylvain.leroy@tocea.com / @sleroy0 about.me/sylvain_leroy 2007 Ingénieur Recherche Informatique 2011 Création Société Tocea 2014 Acquisition Tocea Groupe Metrixware CTO Tocea 2015 Acquisition Echoes Groupe Metrixware CTO MetrixwareProjet Recherche
    3. 3. Ma Société ▧ Assistance Qualité / Recette applications ▧ Modernisation automatique d’applications ▧ Offre Intégration Usine Logicielle ▧ Formateurs Bonnes Pratiques /Cleancode / Qualité / Devops ▧ Distributeur Outils de qualité de code (Optimyth) ▧ Komea Dashboard (Pilotage développements par la qualité/productivité) ▧ Offres Cobol/Mainframe
    4. 4. La qualité logicielle?
    5. 5. “ De quoi est composé un logiciel ?
    6. 6. Les programmes, Les procédures, La documentation, Les données, Les scripts, Les tests...
    7. 7. Qu’est ce que pour vous un logiciel de qualité ?
    8. 8. Logiciel qui combine un faible taux de défauts et un haut niveau de satisfaction utilisateur. Le logiciel doit remplir toutes les exigences utilisateur et adhérer aux standards internationaux. La qualité fonctionnelle Casper Jones
    9. 9. Logiciel qui présente une robuste architecture et peut opérer comme un environnement multi-couches sans panne ou performance dégradée. Le logiciel présente un faible niveau de complexité cyclomatique. La qualité structurelle Casper Jones
    10. 10. Logiciel qui a de l’élégance, de l’ergonomie, avec des commandes faciles à utiliser et des interfaces et des écrans interactifs et des sorties bien présentées. La qualité esthétique Casper Jones
    11. 11. Quels sont les signes révélateurs de non-qualité ?
    12. 12. La complexité de la mesure
    13. 13. La dette technique
    14. 14. La dette technique
    15. 15. Quand les sprints illustrent la dette technique
    16. 16. “Les développements rapides et peu soucieux de la qualité produisent généralement des années de maintenance et d’évolutions coûteuses. La dette technique Ward Cunningham Autre conséquence, un logiciel prend le risque d’être abandonné plus rapidement (vieillissement précoce)
    17. 17. “C’est le coût de ne pas créer un logiciel de qualité. Chaque fois que qu’une partie du logicielle est refaite, le coût de la qualité augmente Le coût de la qualité Principles of Quality Costs, edited by Douglas C. Wood, ASQ Quality Press, 2012.
    18. 18. Dette technique ?
    19. 19. Qualité logicielle = Satisfaire les clients = Traquer les défauts = COnserver sa productivité
    20. 20. Les défauts, évaluation indirecte de la qualité d’un produit
    21. 21. Vocabulaire : ▧ Défauts : …. ▧ Anomalie, Faute : ... ▧ Erreur, Bogue : …. ▧ Défaillance, Incident : ….
    22. 22. Défauts et méthodologie Méthodologie de dev. Taux de défauts potentiel / FP Efficacité de suppression(%) Taux de défauts délivrés / FP Cowboy 5.50 83% 0.94 Cycle en V 5.00 85% 0.75 Itérative 4.75 87% 0.62 Orientée objet 4.50 90% 0.45 Agile avec Scrum 4.30 94% 0.26 Test driven development 4.20 95% 0.21 Unified Process (RUP) 4.15 96% 0.17 PSP et TSP 3.50 97% 0.10 85% Certifié Réutilisation 1.75 99% 0.002
    23. 23. Quelles sont les causes les plus courantes de bugs ?
    24. 24. Les causes de bugs les plus courantes : ▧ Exigences non précises ▧ Spécifications mal rédigés ou absentes ▧ Déviations volontaires des exigences ▧ Erreurs de design ▧ Erreur de codage ▧ Non conformité avec la documentation ou les conventions de codage ▧ Tests insuffisants ▧ Processus insuffisamment industrialisé ▧ Erreurs dans la documentation
    25. 25. Quelles sont les justifications les plus courantes?
    26. 26. Ceci est une fonctionnalité
    27. 27. TOP 20 Justifications les plus courantes ▧ Cela fonctionne sur ma machine ▧ Ou étiez-vous quand le programme a crashé ? ▧ Pourquoi voulez-vous faire ceci ainsi ? ▧ Vous n’utilisez pas la bonne version du système d’exploitation ▧ Même si cela ne fonctionne pas, est-ce gênant ? ▧ Avez vous passé l’antivirus ? ▧ Quelqu’un a du changé mon code ▧ Cela fonctionne mais cela n’a pas été testé ▧ Ceci ne peut être à l’origine de Cela! ▧ Je ne peux pas tout tester! ▧ C’est juste une coïncidence malchanceuse ▧ Vous ne devez pas utiliser la dernière version du logiciel ▧ Je n’ai pas touché à ce module depuis des lustres! ▧ Il doit avoir quelque chose de bizarre dans vos données ▧ Qu’avez vous pu taper pour faire planter le logiciel ? ▧ Cela doit être un problème matériel ▧ Comment est-ce possible ? ▧ Cela fonctionnait hier ▧ Cela fonctionne sur ma machine ▧ Cela n’avait jamais cela avant ▧ C’est bizarre ▧ C’est normal, c’est une fonctionnalité
    28. 28. Origine et conséquence des erreurs
    29. 29. Crime et Châtiment Exigences Plus difficiles à prévenir et à corriger L’ajout incessant de fonctionnalités Source très gênante de bugs Architecture Clé pour structurer la qualité Design Plus graves et contaminantes Code source Les plus nombreuses, faciles à corriger Failles de sécurité Difficiles à trouver, difficiles à corriger Documentation Important si non corrigée Mauvaises corrections Difficiles à trouver Mauvais jeux de tests Nombreux mais rarement évalués Mauvaises données Commun mais jamais mesuré Structure Difficile à identifier
    30. 30. (A suivre) L’industrialisation des développements
    31. 31. Merci Vous pouvez me trouver : @sleroy0 sylvain.leroy@tocea.com

    ×