Démarche Qualité Logicielle

1. Démarche Qualité Logicielle Emmanuel PERRIN Laboratoire de RMN Emmanuel.Perrin@univ-lyon1.fr

2. Le cœur du Problème • Disciplines Scientifiques • Problème => cahier des charges • Schéma : analyse du problème • Schéma électronique, mécanique … • Réalisation • Informatique • Problème • Programmation • Pas d’analyse

3. La qualité logicielle comme solution ? • Bien poser le problème • Étape des Spécifications • Spécification Technique de Besoin Logiciel (STBL) (1/4 du budget temps) • Répondre aux spécifications • Étape d’étude/conception du programme • Document d’Architecture Logicielle (DAL) (1/8 du budget temps) • Faire apparaître des briques logicielles • Préparer l’implémentation • Document de Conception Détaillé (DCD) (1/8 du budget temps) • Implémenter en suivant le DCD / Reconception : • Unique étape de Programmation (1/4 du budget temps) • Version modifiée du DCD : inévitable • Version modifiée du DAL • Version modifiée STBL • Fiche de version • Documentation Utilisateur

4. Un exemple concret : résolution du trinôme du second degré • Faire un logiciel qui trouve les solutions de : ax²+bx+c=0 • Spécifications du Programme établies pour un budget temps (2h de programmation en Licence) • Architecture du Logiciel • DCD • Programmation • Validation (remontée DCD => DAL => STBL)

5. Mise en œuvre : documentation normalisée • Fichiers « patrons » sous Word • Remplir tous les champs • Exhaustivité

6. STBL • Question simple • Réponse complexe / nuancée par le budget temps • ax²+bx+c=0 • a, b, c : réels ou complexes • Seul le cas réel est traité • Solutions dans le corps des réels (discriminant positif ou nul) • Langage - Système d’exploitation (Windows/Unix) • Pas de tracé graphique (+cher en temps) • Notion de contrat / négociation / budget temps • Description des fonctionnalités • Entrées • Traitement • Sorties • Conditions de validation • Validation • Client (enseignant) • Concepteur (etudiant) • Chef de projet (enseignant)

7. DAL • C’est une réponse possible à la STBL • en informatique : pas d’unicité de la solution ! • Dépend : • des objectifs • des contraintes • des connaissances de l’étudiant • des impératifs techniques (OS/Langage) • Notion de projet individuel • Le DAL permet (validation) • au concepteur (étudiant) d’analyser / concevoir • au chef de projet (enseignant) d’analyser la faisabilité du projet

8. DCD • Chaque fonctionnalité est décrite en terme de fonctions logicielles • Entrées (type, nombre) • Traitements (algorithmes) • Sorties (type, nombre) • Vecteur de test • Entrées => Sorties => Validation

9. Phase de programmation • Suivre le DCD • Phase critique pour l’étudiant • Facilitée : suivre un canevas • Validation étape par étape

10. Bénéfices • Fixer des objectifs précis • Disposer d’une méthodologie de travail • Gérer les impératifs techniques • La Documentation normalisée ne nuit pas à l’expression personnelle !

11. Exemple I • Audiodetector • Start-up domaine sécurité • Démonstrateur logiciel • Stage / emploi 6 mois + 3 mois école • Encadrement Informatique / Scientifique • Orléans / Sophia Antipolis • Mail / Doc. Qualité • Respect de la documentation qualité

12. Exemple II • Travail coopératif • 3 séances de 2h TP, 1 groupe de 15 étudiants, • Plus de 6 heures de travail • Optimisation 1D / 2D / 3D

13. Exemple III • Programmation Objet • UML

14. Conclusion • Approche : « la Qualité par l’Exemple » • La qualité comme outil méthodologique