Démarche Qualité Logicielle Infomaths.jimdo.com

Le cœur du Problème Disciplines Scientifiques Informatique 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

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

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)

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

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)

DAL C’est une réponse possible à la STBL Dépend : 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

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

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

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 !

Exemple I Audiodetector Encadrement Informatique / Scientifique 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é

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

Exemple III Programmation Objet UML

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